Re: [systemd-devel] [PATCH] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities
On Mar 3, 2015, at 8:55 AM, Topi Miettinen
toiwo...@gmail.commailto:toiwo...@gmail.com wrote:
On 03/03/15 01:28, Jay Faulkner wrote:
Hey,
Lennart reviewed this in IRC and suggested I refactor the change in this
manner. Now, we have an array of capability:sys call pairs, and iterate
through that and then only add the seccomp filter if the capability
doesn’t exist.
The new patch is attached, and available
here: https://github.com/jayofdoom/systemd/pull/5.patch.
+typedef struct CapSeccompPair {
+uint64_t capability;
+int scmp_syscall_num;
+} CapSeccompPair;
...
+static const CapSeccompPair blacklist[] = {
+{ SCMP_SYS(iopl), CAP_SYS_RAWIO },
The fields are swapped.
-Topi
Thanks for the review! I’ve corrected the issue, and have the new patch
attached and available here: https://github.com/jayofdoom/systemd/pull/5.patch.
-Jay Faulkner
nspawn-capabilty-seccomp.patch
Description: nspawn-capabilty-seccomp.patch
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities
Hey, Lennart reviewed this in IRC and suggested I refactor the change in this manner. Now, we have an array of capability:sys call pairs, and iterate through that and then only add the seccomp filter if the capability doesn’t exist. The new patch is attached, and available here: https://github.com/jayofdoom/systemd/pull/5.patch. nspawn-seccomp-capabilities.patch Description: nspawn-seccomp-capabilities.patch Thanks all,Jay FaulknerOn Feb 27, 2015, at 12:15 PM, Jay Faulkner j...@jvf.cc wrote:Hi all,My apologies if this is frowned upon, but this has been posted for a week and I haven’t gotten any feedback on it. I’d appreciate if this could get reviewed and if adequate, merged. I’m waiting on this change in order to be able to continue using systemd-nspawn containers, properly configured, to perform system tasks (such as firmware and bios flashing).Thanks,Jay FaulknerOn Feb 20, 2015, at 6:59 PM, Jay Faulkner j...@jvf.cc wrote:After some additional testing, I found a bug in this patch where it would not compile with seccomp disabled. I’ve updated the patch athttps://github.com/jayofdoom/systemd/pull/4.patch— also I’ve attached the fixed patch.-Jayrefactor-nspawn-map-seccomp-to-capabilities.patchOn Feb 20, 2015, at 4:18 PM, Jay Faulkner j...@jvf.cc wrote:Hi all,At the suggestion (and with the assistance of) a co-worker, we remade this patch to not have quite as much repeated code. The new version is attached and can be found herehttps://github.com/jayofdoom/systemd/pull/4.patch— thanks!refactor-nspawn-map-seccomp-to-capabilities.patchThanks,Jay FaulknerOn Feb 20, 2015, at 2:24 PM, Jay Faulkner j...@jvf.cc wrote:Hi all,Two weeks ago[1] I patched systemd-nspawn to respect CAP_SYS_MODULE with regards to setting seccomp filters. As I needed access to some of the other blocked syscalls as well, I have a patch to map all seccomp filters to various capabilities, and to only set those filters if the matching capability is dropped. The matching capabilities were taken from the man pages of the syscalls involved.I’d also suggest that in the future, additional filters use this same mapping as to avoid breaking use cases like mine in the future. :)The patch is attached, but in case it gets mangled in transport as the last one did, feel free to get it directly from github here: https://github.com/jayofdoom/systemd/pull/3.patch.Thanks,Jay Faulknernspawn-map-seccomp-to-capabilities.patch___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/systemd-devel___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/systemd-devel___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/systemd-devel___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://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] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities
Hi all, My apologies if this is frowned upon, but this has been posted for a week and I haven’t gotten any feedback on it. I’d appreciate if this could get reviewed and if adequate, merged. I’m waiting on this change in order to be able to continue using systemd-nspawn containers, properly configured, to perform system tasks (such as firmware and bios flashing). Thanks, Jay Faulkner On Feb 20, 2015, at 6:59 PM, Jay Faulkner j...@jvf.ccmailto:j...@jvf.cc wrote: After some additional testing, I found a bug in this patch where it would not compile with seccomp disabled. I’ve updated the patch at https://github.com/jayofdoom/systemd/pull/4.patch — also I’ve attached the fixed patch. -Jay refactor-nspawn-map-seccomp-to-capabilities.patch On Feb 20, 2015, at 4:18 PM, Jay Faulkner j...@jvf.ccmailto:j...@jvf.cc wrote: Hi all, At the suggestion (and with the assistance of) a co-worker, we remade this patch to not have quite as much repeated code. The new version is attached and can be found here https://github.com/jayofdoom/systemd/pull/4.patch — thanks! refactor-nspawn-map-seccomp-to-capabilities.patch Thanks, Jay Faulkner On Feb 20, 2015, at 2:24 PM, Jay Faulkner j...@jvf.ccmailto:j...@jvf.cc wrote: Hi all, Two weeks ago[1] I patched systemd-nspawn to respect CAP_SYS_MODULE with regards to setting seccomp filters. As I needed access to some of the other blocked syscalls as well, I have a patch to map all seccomp filters to various capabilities, and to only set those filters if the matching capability is dropped. The matching capabilities were taken from the man pages of the syscalls involved. I’d also suggest that in the future, additional filters use this same mapping as to avoid breaking use cases like mine in the future. :) The patch is attached, but in case it gets mangled in transport as the last one did, feel free to get it directly from github here: https://github.com/jayofdoom/systemd/pull/3.patch. Thanks, Jay Faulkner nspawn-map-seccomp-to-capabilities.patch ___ systemd-devel mailing list systemd-devel@lists.freedesktop.orgmailto:systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.orgmailto:systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.orgmailto: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
[systemd-devel] [PATCH] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities
Hi all, At the suggestion (and with the assistance of) a co-worker, we remade this patch to not have quite as much repeated code. The new version is attached and can be found here https://github.com/jayofdoom/systemd/pull/4.patch — thanks! refactor-nspawn-map-seccomp-to-capabilities.patch Description: refactor-nspawn-map-seccomp-to-capabilities.patch Thanks,Jay FaulknerOn Feb 20, 2015, at 2:24 PM, Jay Faulkner j...@jvf.cc wrote: Hi all, Two weeks ago[1] I patched systemd-nspawn to respect CAP_SYS_MODULE with regards to setting seccomp filters. As I needed access to some of the other blocked syscalls as well, I have a patch to map all seccomp filters to various capabilities, and to only set those filters if the matching capability is dropped. The matching capabilities were taken from the man pages of the syscalls involved. I’d also suggest that in the future, additional filters use this same mapping as to avoid breaking use cases like mine in the future. :) The patch is attached, but in case it gets mangled in transport as the last one did, feel free to get it directly from github here: https://github.com/jayofdoom/systemd/pull/3.patch. Thanks, Jay Faulkner nspawn-map-seccomp-to-capabilities.patch___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://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] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities
After some additional testing, I found a bug in this patch where it would not compile with seccomp disabled. I’ve updated the patch at https://github.com/jayofdoom/systemd/pull/4.patch — also I’ve attached the fixed patch. -Jay refactor-nspawn-map-seccomp-to-capabilities.patch Description: refactor-nspawn-map-seccomp-to-capabilities.patch On Feb 20, 2015, at 4:18 PM, Jay Faulkner j...@jvf.cc wrote: Hi all, At the suggestion (and with the assistance of) a co-worker, we remade this patch to not have quite as much repeated code. The new version is attached and can be found herehttps://github.com/jayofdoom/systemd/pull/4.patch— thanks! refactor-nspawn-map-seccomp-to-capabilities.patchThanks,Jay FaulknerOn Feb 20, 2015, at 2:24 PM, Jay Faulkner j...@jvf.cc wrote: Hi all, Two weeks ago[1] I patched systemd-nspawn to respect CAP_SYS_MODULE with regards to setting seccomp filters. As I needed access to some of the other blocked syscalls as well, I have a patch to map all seccomp filters to various capabilities, and to only set those filters if the matching capability is dropped. The matching capabilities were taken from the man pages of the syscalls involved. I’d also suggest that in the future, additional filters use this same mapping as to avoid breaking use cases like mine in the future. :) The patch is attached, but in case it gets mangled in transport as the last one did, feel free to get it directly from github here: https://github.com/jayofdoom/systemd/pull/3.patch. Thanks, Jay Faulkner nspawn-map-seccomp-to-capabilities.patch___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/systemd-devel___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/systemd-devel___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] nspawn: Map all seccomp filters to matching capabilities
Hi all, Two weeks ago[1] I patched systemd-nspawn to respect CAP_SYS_MODULE with regards to setting seccomp filters. As I needed access to some of the other blocked syscalls as well, I have a patch to map all seccomp filters to various capabilities, and to only set those filters if the matching capability is dropped. The matching capabilities were taken from the man pages of the syscalls involved. I’d also suggest that in the future, additional filters use this same mapping as to avoid breaking use cases like mine in the future. :) The patch is attached, but in case it gets mangled in transport as the last one did, feel free to get it directly from github here: https://github.com/jayofdoom/systemd/pull/3.patch. Thanks, Jay Faulkner nspawn-map-seccomp-to-capabilities.patch Description: nspawn-map-seccomp-to-capabilities.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
On Feb 3, 2015, at 3:52 PM, Lennart Poettering lenn...@poettering.net 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
[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
[systemd-devel] systemd-nspawn support for loading kernel modules / custom seccomp rules
Hi all, I’m a big fan of systemd, and currently use IPA[1] running inside systemd-nspawn containers to provision and maintain systems as part of OpenStack Ironic. This includes, at times, doing things like flashing firmwares which may require a kernel module to be loaded. Currently, we’re using CoreOS 367.0.0 with 3.15.2 kernel and systemd 212. Recently, I attempted an upgrade to CoreOS 575.0.0 with kernel 3.18.2 and systemd 218 and found I could no longer load kernel modules from inside an nspawn container. This appears to be related to some seccomp filters added/enabled in systemd 215. Is it possible to have a switch added to systemd-nspawn to allow me to specify custom seccomp filters, or to disable them entirely? The only alternative to this for my use case is to not use containers at all or to preload all modules needed before launching my container. The 1st option doesn’t work well because CoreOS doesn’t ship with sufficient OS resources to run IPA inside it, and the second is not reasonable because the same IPA ramdisk is used across many nodes on a fleet, which may have different hardware and therefore different modules are required to perform things like BIOS flashing. Thanks in advance, Jay Faulkner [1] https://github.com/openstack/ironic-python-agent; relevent nspawn flags here: https://github.com/openstack/ironic-python-agent/blob/master/imagebuild/coreos/oem/cloud-config.yml#L40 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
