On Tue, 03.02.15 23:22, Jay Faulkner (j...@jvf.cc) wrote: > Hi all, > > As I posted last week, a change merged a while ago to systemd-nspawn > adding seccomp protections with no ability to enable/disable broke > the Ironic Python Agent ramdisk which utilizes CoreOS and > systemd. The attached patch makes the behavior optional, with it > defaulting to disabled. I did this for two reasons; the first being > that my (and other consumers of OpenStack Ironic) use case was > broken, as would anyone else using spawn in this > manner. Additionally, seccomp filters can be configured specifically > as desired in the unit file.
This was about allowing kernel module loading from inside nspawn containers? I completely missed that we actually really have seccomp filters to disallow that in place... We hence have two layers of security there to turn off kernel module loading: seccomp and the missing CAP_SYS_MODULE capability. I am not particularly fond of the idea of adding a completely new command line option for this though. Maybe we can find another way for this. For example, one option could be to split the seccomp syscall blacklist in two: split out the kernel kmod related syscalls, and only add them to the seccomp filter if arg_retain does not include CAP_SYS_MODULE. This would then leave the module seccomp filters in place by default, however, if you add the CAP_SYS_MODULE cap to the container with --capability= then the seccomp filter is changed to also allow the module loading syscalls. The patch is corrupted, it includes Windows new lines. If you rework the patch as suggested above, and send it as uncorrupted patch, I'd be happy to merge it. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel