LSM namespacing API

[Paul Moore]

On Tue, Mar 3, 2026 at 11:46 AM Paul Moore <paul at paul-moore.com> wrote:
>
> 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.

It's been three weeks now, and I haven't seen any strong arguments for
supporting the clone() API at this time, so we can leave that out for
now and stick with just the unshare() API for an initial attempt.  We
can always add a clone() API at a later date if needed; going small
and expanding over time is usually a better decision anyway.

So to quickly summarize, here is where I think the discussion landed:

* Implement the lsm_unshare() syscall

I expect it would look something like 'lsm_unshare(struct lsm_ctx
*ctx, u32 size, u32 flags)' with @ctx specifying the particular LSM
being unshared, and @flags being 0/unused at this point in time
(unless we can think of something we want to specify here).  Like
lsm_set_self_attr(), only one @ctx can be specified at a time, so you
can only unshare one LSM at a time.

* Implement /proc/pid/ns/lsm and setns(CLONE_NEWLSM)

As discussed previously, this allows us to move a process into an
existing, established LSM namespace set.  The caller cannot
selectively choose which individual LSM namespaces they join from the
given LSM namespace set, they receive the same LSM namespace
configuration as the target process.

Any comments, corrections, etc.?  If not, if someone wants to send me
a patch{set} implementing these changes we can merge them into
lsm/dev-staging until we have a LSM which implements support for the
new API.

-- 
paul-moore.com