On Tue, 2016-01-19 at 10:16 +0100, Nikos Mavrogiannopoulos wrote:
The issue is that blacklists are terrible from a security
standpoint.
That means that every new obscure system call added to the kernel
will
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
does.)
It is useful regardless to blacklist a few syscalls that you know your
application really should not be using. kexec is probably the best
example.
That does sound like a very fragile usage of seccomp indeed.
It was a bad idea. :)
It could
be solved of course by using IPC to open a file rather than relying
on
the signal.
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
not investigated).
Then the question for programs wanting to use glibc and seccomp
would
be, could libc keep the syscalls fixed for its wrapper of system
calls,
Even simply documenting the possible syscalls would be helpful to
programmers using seccomp, although apps are still going to break in
the future.
or could we have filters which are applied to glibc's calls
rather
than
system calls?
I don't think so. seccomp filters are per-process.
Michael