On Fri, 2017-10-06 at 14:24 -0500, Serge E. Hallyn wrote: > Quoting Stephen Smalley (sds@xxxxxxxxxxxxx): > > On Fri, 2017-10-06 at 12:07 +1100, James Morris wrote: > > > On Mon, 2 Oct 2017, Stephen Smalley wrote: > > > > > > > This change presumes that one will always unshare the network > > > > namespace > > > > when unsharing a new selinux namespace (the reverse is not > > > > required). > > > > Otherwise, the same inconsistencies could arise between the > > > > notifications > > > > and the relevant policy. At present, nothing enforces this > > > > guarantee > > > > at the kernel level; it is left up to userspace (e.g. container > > > > runtimes). > > > > It is an open question as to whether this is a good idea or > > > > whether > > > > unsharing of the selinux namespace should automatically unshare > > > > the > > > > network > > > > namespace. > > > > > > What about logging a kernel warning if just SELinux is unshared? > > > > As with Serge's suggestion, the problem is that one can unshare > > them in > > any order, and potentially with intervening steps to set up the > > But is it going to stay that way? I thought that was a temporary > thing > while you test it out. > > Because as it is it seems unacceptably loose. A few questions: > > (thinking as I type here - ok only the last one is the real question) > > Assume I'm in my given netns. I unshare just my selinuxns. Does the > selinuxns have the authority to decide things about that netns? > > If I unshare selinuxns+netns, then the selinuxns clearly "owns" the > netns, > so the selinuxns has clear authority. Likewise, when I unshare the > netns after the selinuxns, from that point on the selinuxns can be > said > to have authority over the netns. > > I think you want to keep it completely orthogonal, and I guess so > long > as the parent selinuxns policy still applies it's ok. > > So I unshare my selinuxns but not userns. I don't have CAP_MAC_ADMIN > against the user_ns, so any selinux related changes will be denied. > Once I unshare userns, they will be allowed. > > Ah, right. Here's the real question. Policy dictates file > transition > rules. How will those be namespaced? Will only the init_selinux_ns > be > allowed to specify a file context? You can't let > ns_capable(current_selinux_ns, > CAP_MAC_ADMIN) guide that safely, but capable(CAP_MAC_ADMIN) will be > very restrictive. What's the plan there? Sorry if it's spelled out > elsewhere. I don't think we know yet. The current patches support a separate and distinct in-core inode security context for each namespace, which supports scenarios such as using context mounts on the host OS to label each container with a single context with MCS separation while using per-file xattrs within a container to support a conventional targeted policy, but we haven't yet resolved how to deal with the actual persistent file security contexts, e.g. whether there will be only one (possibly with a label mapping defined) or multiple.
