Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Colin Watson <cjwatson@debian.org>]

On Wed, Nov 29, 2017 at 05:36:30PM -0800, Russ Allbery wrote:
> Vincas Dargis <vindrg@gmail.com> writes:
> > Since mentioned, I would like that these daemons would implement seccomp
> > filtering themselves, meaning like within application itself, using
> > libeseccomp. Thy can fine-grain what thread what syscalls can make.
[...]
> Does libeseccomp now have maintained system call classes similar to
> systemd?

(I think "libeseccomp" was a typo for "libseccomp".  I wouldn't normally
bother to point this out, but you reproduced it, and it caused me to
briefly get excited at the idea that maybe there was an "extended
seccomp" library or something.)

As far as I can tell, no.  I've been working on applying seccomp
confinement to parts of man-db recently (there are plenty of bits of its
code that could usefully be hardened against the admittedly small chance
of a compromise via crafted manual page text).  I have the self-imposed
spec of "should allow the process to do most reasonable things to
itself, to read and write data from and to already-open file
descriptors, to open files in read-only mode, and to fork new processes
with the same restrictions".  This results in a list of 116 syscalls at
last count, and it's hard to be certain that such a list is complete.
Since this is in application code rather than service code, systemd's
SystemCallFilter predefined sets aren't directly usable in this context;
I'd definitely like to use a library that provided something similar,
maybe a wrapper on top of libseccomp.

(Hmm, though maybe a reasonable stopgap would be to copy the relevant
syscall lists from systemd's code.  That would leave me updating things
manually from time to time, which isn't great, but it would probably
still be better than maintaining my own list!  I think I'll do this.)

-- 
Colin Watson                                       [cjwatson@debian.org]