On Mon, 2016-01-18 at 09:51 -0600, Michael Catanzaro wrote: > > I appreciate what you are trying to do, but those seccomp filters > > totally break encapsulation. I have no idea how to support this > > properly, in a sustainable way. It appears very difficult to do > > this > > for independently evolving libraries. > > No matter what, any seccomp whitelist is doomed to break in the > future > if your program uses shared libraries (including glibc). I think > seccomp filters can reasonably be used with a blacklist of syscalls, > but not with a whitelist. 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. > An anecdote: in WebKit (which has a seccomp filter sandbox not > compiled > by default, because it is unfinished and very fragile), the web > process > receives SIGSYS from seccomp when it calls open() or a related > function, which it does not have permission to use; it then passes > the > filename of the file it wants to open via IPC to a broker process, > which evaluates our filesystem policy, opens the file (if > permissible), > and sends the fd to the web process via a UNIX socket. This all goes > awry if, in the web process's signal handler, malloc decides to call > open(), triggering an infinite loop of SIGSYS handlers. So we have to > open all files used by malloc (currently > /proc/sys/vm/overcommit_memory > and /sys/devices/system/cpu/online) and cache the fds in the web > process before initializing seccomp filters. libseccomp could not > help > with that, since there are so many different ways to use seccomp; it > doesn't know anything about our broker processs. That does sound like a very fragile usage of seccomp indeed. It could be solved of course by using IPC to open a file rather than relying on the signal. In any case seccomp certainly requires a program to be restructured or designed in a way to have a limited to syscall requirements component to have seccomp enabled (e.g., only to glibc). If you cannot have that then seccomp is probably not the answer. 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, or could we have filters which are applied to glibc's calls rather than system calls? Otherwise the only remaining solution would be for applications requiring seccomp to switch to thinner libc variants. regards, Nikos -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
