On Tue, 2016-01-19 at 10:16 +0100, Nikos Mavrogiannopoulos wrote:
The issue is that blacklists are terrible from a security
That means that every new obscure system call added to the kernel
be available by default in your program.
Yes. This implies that seccomp should not be the primary enforcement
mechanism for a sandbox, unless you static link to your dependencies to
prevent the syscalls from unexpectedly changing. (This is what Chrome
It is useful regardless to blacklist a few syscalls that you know your
application really should not be using. kexec is probably the best
That does sound like a very fragile usage of seccomp indeed.
It was a bad idea. :)
be solved of course by using IPC to open a file rather than relying
The kernel provides a couple options here: it can kill the process when
it calls open(), or it can send SIGSYS (in which case the only way for
the file to be opened is via IPC to a less-constrained process; this is
what we do), or it can notify another process via ptrace (which I have
Then the question for programs wanting to use glibc and seccomp
be, could libc keep the syscalls fixed for its wrapper of system
Even simply documenting the possible syscalls would be helpful to
programmers using seccomp, although apps are still going to break in
or could we have filters which are applied to glibc's calls
I don't think so. seccomp filters are per-process.