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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
