LSM namespacing API

[Paul Moore]

On Tue, Mar 3, 2026 at 8:30 AM Stephen Smalley
<stephen.smalley.work at gmail.com> wrote:
> On Wed, Feb 25, 2026 at 7:05 PM Paul Moore <paul at paul-moore.com> wrote:
> > I spent a few hours this afternoon re-reading this thread and tweaking
> > the original proposal to address everything discussed.  The revised
> > proposal is below, with a bit more detail than before, please take a
> > look and let us all know what you think ...

[Yet another reminder to please consider trimming your replies.]

> I think my only caveat here is that your proposal is quite a bit more
> complex than what I implemented here:
> [1] https://lore.kernel.org/selinux/20251003190959.3288-2-stephen.smalley.work@gmail.com/
> [2] https://lore.kernel.org/selinux/20251003191328.3605-1-stephen.smalley.work@gmail.com/
> and I'm not sure the extra complexity is worth it.
>
> In particular:
> 1. Immediately unsharing the namespace upon lsm_set_self_attr() allows
> the caller to immediately and unambiguously know if the operation is
> supported and allowed ...

Performing the unshare operation immediately looks much less like a
LSM attribute and more like its own syscall.  That isn't a problem in
my eyes, it just means if this is the direction we want to go we
should implement a lsm_unshare(2) API, or something similar.

> 3. We don't need to introduce a new CLONE_* flag at all or introduce
> new or changed LSM hooks to clone/unshare,

While I think we could get away with a new lsm_unshare(2) syscall, I
have zero interest in an lsm_clone(2) syscall.  If we do away with the
namespace related LSM attributes and rely entirely on a lsm_unshare(2)
syscall, would everyone be okay with that?

(I think we would still want/need the procfs API)

> All that said, I'm willing to wire up the SELinux namespaces
> implementation to the proposed interface if someone implements the
> necessary plumbing, but I'm not sure it's better.

I'd really like to hear from some of the other LSMs before we start
diving into the code.  It may sound funny, but from my perspective
doing the work to get the API definition "right" is far more important
than implementing it.

-- 
paul-moore.com