On Thu, 2017-03-09 at 10:28 -0500, Stephen Smalley wrote: > On Thu, 2017-03-09 at 17:03 +0800, yangshukui wrote: > > > > I want to use SELinux in system container and only concern the > > function > > in the container. > > this system container run in vm and every vm has only one system > > container. > > > > How do I use now? > > docker run ... system-contaier /sbin/init > > after init is running ,the following service is also running: > > > > #this is the part of service file which will run in container > > after > > starting the container. > > ... > > semodule -R #use the policy in container. > > restorecon / #if needed > > ... > > > > this method seem to work if host os and the docker images use the > > same > > content for rootfs, but if host use > > redhat7 and docker images use centos7, it will deny many normal > > operations , and this let some host service not work. > > > > If SELinux is permissive in host and enforcing in container ,it > > will > > resolve my problem. Unfortunately, > > there is no namespace for SELinux. > > > > Isolate SELinux is difficult and it has a lot of work to do, but > > is > > easier to isolate selinux_enforcing. > > > > What do you think ? > > I'd rather see proper SELinux policy namespace support implemented. > Admittedly, that won't be straightforward. > > FWIW, ChromiumOS appears to have done something similar to what you > suggest for supporting Android containers (i.e. SELinux enforcing for > the Android container, permissive for ChromiumOS processes outside > the > container), but they never discussed it with upstream SELinux > developers AFAIK. My only knowledge of what they have done comes > from > their kernel repository [1]. It appears that they experimented with a > hack to narrow the scope of selinux_enforcing to a PID namespace [2], > then reverted that change later and just implemented an option to > suppress audit denials for permissive domains [3] (evidently they are > running the Chromium OS processes in a permissive domain; I haven't > seen their policy). I wouldn't recommend either approach; the former > won't properly handle permission checks that occur outside of process > context or certain permission checks where the source context is not > the current task context (e.g. an inter-object relationship check), > while the latter requires leaving a permissive domain in the > production > policy (which seemingly would violate CTS; not sure why that gets a > pass, and if that is ok, then why didn't they just create a domain > allowed all permissions and use that outside the container instead - > then they won't need to suppress audit at all?) and further requires > use of a separate kernel for policy development/debugging. Note btw > that they could have silenced the permissive denials via dontaudit > rules instead (as Android does for its su domain) but chose not to do > so to avoid taking the slow path. Sorry, should have looked more closely at their actual change - that last part of their rationale is bogus; a dontaudit rule would have prevented calling slow_avc_audit() at all, whereas their change merely returns early from slow_avc_audit(). So I really don't understand why they didn't just define dontaudit rules for all permissions (if using a permissive domain) or allow rules for all permissions (if using an enforcing, allow-all domain). Neither one is especially hard to write, and they could have just looked at the su domain in Android for an example of the former. > > [1] https://chromium.googlesource.com/chromiumos/third_party/kernel > [2] https://chromium-review.googlesource.com/c/361464/ > [3] https://chromium-review.googlesource.com/c/424948/ _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
