isolate selinux_enforcing

[sds@tycho.nsa.gov (Stephen Smalley)]

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.

[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