Quoting Dwight Engen (dwight.en...@oracle.com): > This change proposes to add support to LXC for additional LSMs (Linux > Security Module), namely SELinux. It does so by turning the existing
Thanks, Dwight! I do some bikeshed arguing below, but I will do a closer review next week, hopefully monday. > AppArmor calls into generic lsm_* calls, which are then handled by one > of three LSM drivers: AppArmor, SELinux, or a nop driver. Adding a > SMACK driver should be fairly simple. The nop driver is used when LXC > has compiled in support for AppArmor or SELinux but neither is enabled > in the run time environment. > > One minor point of discussion should be whether to keep the aa_profile > configuration item and have a separate selinux_context item, or to use the > approach taken in this patch which is to genericize the name to lsm_label. > Using a single lsm_label implies that the policies will never be used > together, which I believe is likely a safe assumption. You might be right on this, but there are two counter-arguments, and I'm not sure where I stand. The first counter argument is that I might want to share a config or config excerpt (i.e. lxc.include) between several hosts, some of which are apparmor-enabled and some selinux-enabled. Or even migrate or stop-and-move a container between such hosts. Ignoring the labeling issue :) that would not be possible with this setup. Secondly, there *is* on-going work, with a non-zero chance of inclusion, to enable stacking LSMs in the kernel. I doubt that even i that case you'd want to use both to confine the container, but one never knows. You might want to use apparmor to confine the container as seen from the container, while specifying that the contaienr should start as unconfined_t so that the selinux policy in the container can work. (Far-fetched, I agree.) Thirdly, we would at least want lxc.aa_profile to be handled as a valid legacy case so that existing containers don't break > A larger issue is the semantics around when lxc changes profile/context. > Currently, the AppArmor backend uses aa_change_profile() which changes the > profile immediately. No analog exists in SELinux, so the SELinux backend > uses setexeccon_raw() which only takes effect upon exec(2). We could change > the AppArmor backend to use aa_change_onexec() to give them similar > semantics, but this would possibly break callers relying on the "immediate Note that I wanted to use the aa_change_onexec() originally, but did not only because it was broken at the time. > change" behavior (in particular users of the new attach API calling a > function). I don't know how widespread this reliance might be, but I don't > think that model is supportable in SELinux. The current patch does not try > to resolve the difference, I guess one option is to just leave it that way. > Definitely looking for some guidance here. In general "now" vs "on-exec" seem to be the two main ways to change contexts so I think it's fine to support both. > I tested this with Ubuntu to try and make sure I didn't break AppArmor > (in both lxc-start and lxc-attach, cat /proc/self/attr/current show > "lxc-container-default (enforce)"). I've also tested this on > OracleLinux with an in progress SELinux policy module which I can post > if its useful. I've also build tested on Fedora and run unconfined, but > have not written a policy there. ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
