LSM namespacing API

[Paul Moore]

On Thu, Aug 21, 2025 at 3:23 AM John Johansen
<john.johansen at canonical.com> wrote:
> On 8/19/25 11:40, Paul Moore wrote:
> > On Tue, Aug 19, 2025 at 1:11 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> >>
> >> The advantage of a clone flag is that the operation is atomic with
> >> the other namespace flag based behaviors. Having a two step process
> >>
> >>          clone(); lsm_set_self_attr(); - or -
> >>          lsm_set_self_attr(); clone();
> >>
> >> is going to lead to cases where neither order really works correctly.
> >
> > I was envisioning something that works similarly to LSM_ATTR_EXEC
> > where the unshare isn't immediate, but rather happens at a future
> > event.  With LSM_ATTR_EXEC it happens at the next exec*(), with
> > LSM_ATTR_UNSHARE I imagine it would happen at the next clone*().
>
> I do think something like this is needed to deal well with the two
> step process. Without it is fairly easy to get into situations
> where you either need more permissions, than strictly necessary,
> because of steps in between or as Casey says things just don't work
> correctly.

I think we're starting to all coalesce on this basic idea now, at
least for creating new LSM namespace sets, that's good.  As the only
LSM that really has a namespace currently, would AppArmor be able to
work within the lsm_set_self_attr(2) approach, or would you need
something a bit different?  If so, can you give us a basic idea of
what AA would need to work?

> There will need to be an additional call that allows entering a
> namespace separately from clone/unshare, but that covers a different
> use case.

In this particular case I've been thinking of not allowing the same
level of arbitrary LSM namespace composability, but rather limiting
the caller to the set of LSM namespaces already configured for a given
process, using the procfs/setns(2) mechanism.  Does that work for your
use case(s), or do you need more flexibility?

-- 
paul-moore.com