[lxc-devel] [PATCH RFC 0/1] refactor AppArmor into LSM backend, add SELinux support

Dwight Engen dwight.engen at oracle.com
Thu Sep 19 21:51:56 UTC 2013


This change proposes to add support to LXC for additional LSMs (Linux
Security Module), namely SELinux. It does so by turning the existing
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.

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

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.




More information about the lxc-devel mailing list