[systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional
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. I appreciate your time and effort in getting this patch merged, so I’ll be able to upgrade and consume a newer systemd. Thanks, Jay Faulkner systemd-nspawn-seccomp-default-disable.patch Description: systemd-nspawn-seccomp-default-disable.patch ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional
For context this puts a toggle on this feature added to nspawn: http://cgit.freedesktop.org/systemd/systemd/commit/?id=28650077f36466d9c5ee27ef2006fae3171a2430 I encouraged Jay to make it an opt-in flag so as to not break other people who had working setups when using nspawn as a minimal ns wrapper. Brandon On Tue, Feb 3, 2015 at 3:22 PM, Jay Faulkner 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. > > I appreciate your time and effort in getting this patch merged, so I’ll be > able to upgrade and consume a newer systemd. > > Thanks, > Jay Faulkner > > > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional
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
Re: [systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional
> On Feb 3, 2015, at 3:52 PM, Lennart Poettering wrote: > > 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? > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional
On Wed, 04.02.15 02:21, Jay Faulkner (j...@jvf.cc) wrote: > > 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. Applied, thanks! > 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. Yupp, I thought that was pretty much what I was saying on IRC. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
