[Bug 3478] Default "kill" action of seccomp sandbox is fragile

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3478

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Colin Watson from comment #0)
> From time to time, glibc changes its syscall wrappers to make use of
> new Linux kernel facilities.  The strategy it uses for this is often
> to try more recently-introduced syscalls, but fall back to older
> ones if it gets ENOSYS, allowing it to cope gracefully with running
> on older kernel versions.

Arbitrarily failing syscalls that do not normally fail has been the
source of serious security vulnerabilities in the past (eg
CVE-2000-0506).  That's why the default action is "kill" instead of
"fail" and others are considered on a case by case basis.

> it's fragile and typically reactive

You omitted "architecture dependent" :-)  Our CI tests on amd64, i386,
arm, arm64, mips, mipsel and riscv64 but it's impossible for us to
cover every architecture/kernel/glibc combination.

> sandboxing using
> Linux's seccomp inherently violates the abstraction layer of C
> library calls to at least some extent, forcing programs that use it
> to keep track of changes to the C library.

I think that's a pretty good argument that glibc should provide an
interface that is usable by applications that does not have that
layering violation.  Even just being able to specify the filters by
libc function name rather than syscall name would help a lot, however I
suspect doing that would be challenging given that the kernel and glibc
are developed independently.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.