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

[Jay Faulkner]

> On Feb 3, 2015, at 3:52 PM, Lennart Poettering <lennart at poettering.net> wrote:
> 
> 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?
> 

Yes, exactly.

> 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.
> 

As I discovered looking through the code; setting capability=all
prevents *any* capabilities from being dropped, which means I was covered
on this until the change was merged to add seccomp support.

> 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 sys calls.

I implemented this; the patch can be pulled directly from
https://github.com/jayofdoom/systemd/pull/2.patch to prevent me from
corrupting this along the way.

As a note; unlike what we discussed in IRC, someone passing capability=all
will be covered for module loading in this situation, because all sets the
bitmask to -1, effectively enabling all capabilities.

Thanks,
Jay Faulkner

> 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