On Wed, Nov 29, 2017 at 05:36:30PM -0800, Russ Allbery wrote: > Vincas Dargis <vin...@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 [cjwat...@debian.org]