Re: file(1) now with seccomp support enabled
On Sat, 27 Jul 2019 at 10:01:41 +0200, Vincent Bernat wrote:
> Just a quick note: seccomp filters may need adaptations from one libc to
> another (and from one kernel to another as the libc may adapt to the
> current kernel). For example, with the introduction of "openat" syscall,
> the libc has started to use it for "open()" and the new syscall has to
> be whitelisted. On the other hand, if you start implementing seccomp
> filters late, you may have whitelisted only the "openat" syscall while
> older libc (or current libc running on older kernels) will invoke the
> "open" syscall.
Writing your whitelist in terms of groups of related syscalls collected
by some actively-maintained project, like the @basic-io, @ipc, etc. groups
understood by systemd's SystemCallFilter (see systemd.exec(5)), seems like
one way to mitigate this problem.
Another way to mitigate this is to split out the distrusted part of the
program into a helper subprocess that does as little I/O as possible,
and in particular sends input and output via pre-opened pipes or sockets
instead of opening things itself - after all, seccomp is named for
"secure computation", not "secure I/O" or "secure networking". However,
this is probably a lot easier to do for new code than as something that
can be retrofitted onto the assumptions of an existing codebase.
smcv
Reply to: