On Thu, 2017-03-09 at 10:28 -0500, Stephen Smalley wrote:

On Thu, 2017-03-09 at 17:03 +0800, yangshukui wrote:

quoted

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