isolate selinux_enforcing

[Stephen Smalley]

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/

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html