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'm also not sure how one would handle nested
namespaces with this approach, add additional namespace fields to the
label?
--
paul-moore.com
