[systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional

[Lennart Poettering]

On Tue, 03.02.15 23:22, Jay Faulkner (jay at 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