On 10/20/2023 10:29 AM, Paul Moore wrote:
> On Fri, Oct 20, 2023 at 12:16 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
>> On 10/11/2023 3:54 PM, Paul Moore wrote:
>>> Hello all,
>>>
>>> The SELinux namespace effort has been stuck for several years as we
>>> try to solve the problem of managing individual file labels across
>>> multiple namespaces. Our only solution thus far, adding namespace
>>> specific xattrs to each file, is relatively simple but doesn't scale,
>>> and has the potential to become a management problem as a namespace
>>> specific identifier needs to be encoded in the xattr name. Having
>>> continued to think about this problem, I believe I have an idea which
>>> might allow us to move past this problem and start making progress on
>>> SELinux namespaces. I'd like to get everyone's thoughts on the
>>> proposal below ...
>>>
>>> THE IDEA
>>>
>>> With the understanding that we only have one persistent label
>>> per-file, we need to get a little creative with how we represent a
>>> single entity's label in both the parent and child namespaces. Since
>>> our existing approach towards SELinux policy for containers and VMs
>>> (sVirt) is to treat the container/VM as a single security domain,
>>> let's continue this philosophy to a SELinux namespace: a child
>>> namespace will appear as a single SELinux domain/type in the parent
>>> namespace, with newly created processes and objects all appearing to
>>> have the same type from the parent's point of view. From the child
>>> namespace's perspective, everything will behave as they would
>>> normally: processes would run in multiple domains as determined by the
>>> namespace's policy, with files labeled according to the labeling rules
>>> defined in the namespace's policy (e.g. xattrs, context mounts, etc.).
>>> The one exception to this would be existing mounted filesystems that
>>> are shared between parent and child namespaces: shared filesytems
>>> would be labeled according to the namespace which mounted the
>>> filesystem originally (the parent, grandparent, etc.), and those file
>>> labels would be shared across all namespace boundaries. If a
>>> particular namespace does not have the necessary labels defined in its
>>> policy for a shared filesystem, those undefined labels will be
>>> represented just as bogus labels are represented today
>>> ("unlabeled_t"). For this to work well there must be shared
>>> understanding/types between the parent and child namespace SELinux
>>> policies, but if the namespaces are already sharing a filesystem this
>>> seems like a reasonable requirement.
>>>
>>> I'll leave this as an exercise for the reader, but this approach
>>> should also support arbitrary nesting.
>> An SELinux label is currently made up of several components. You
>> could add a new "subdomain" component. The subdomain component would
>> be ignored unless the process is in a namespace, in which case it
>> would be treated as an additional restriction.
> I think the compatibility challenges with adding another field to a
> SELinux label at this point in time, e.g.
> namespace:user:role:type:mls, would make an already challenging task
> almost impossible.
I pretty much figured that. My hope was that since mls is optional, or
at least not always used, there might be some flexibility.
> I'm also not sure how one would handle nested
> namespaces with this approach, add additional namespace fields to the
> label?
My thought was that the subdomain ("namespace" above) would itself
be a SELinux label to which policy specific to the namespace would be
applied. A subdomain, being an SELinux label, could itself have a
subdomain.
But, as you say, compatibility probably kills the notion.
