LSM namespacing API

[Stephen Smalley]

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 ...
>
> * lsm_set_self_attr(LSM_ATTR_CLONE_NEWLSM) and clone(CLONE_NEWLSM)
>
> We would define a new LSM_ATTR flag, LSM_ATTR_CLONE_NEWLSM, which
> could be used with lsm_set_self_attr() to request that an individual
> LSM create a new LSM specific namespace on the next
> clone(CLONE_NEWLSM) call.  LSMs may choose to perform various sanity
> and authorization checks at lsm_set_self_attr() time, but they must
> refrain from creating a new LSM namespace until clone() is called.
> LSMs may also want to ensure that any state associated with an
> lsm_set_self_attr(LSM_ATTR_CLONE_NEWLSM) request is not carried across
> an exec() boundary, however, that decision is left to the individual
> LSMs.
>
> We would define a new clone() flag, CLONE_NEWLSM, which would trigger
> a call into the LSM framework to invoke LSM specific callbacks to
> perform namespace actions specified either by the LSM's policy or an
> explicit lsm_set_self_attr(LSM_ATTR_CLONE_NEWLSM) request.
>
> As with the existing LSM_ATTR support, this is strictly an opt-in
> mechanism and individual LSMs are left to handle this request as they
> see fit.
>
> The lsm_get_self_attr() syscall could be used to get the
> LSM_ATTR_CLONE_NEWLSM value(s) for the current process just like any
> other LSM_ATTR flag.
>
> * lsm_set_self_attr(LSM_ATTR_UNSHARE_NEWLSM) and unshare(CLONE_NEWLSM)
>
> This would behave similarly to LSM_ATTR_CLONE_NEWLSM, but the LSM
> namespace changes would take place during an unshare() call as opposed
> to a clone() call.  This is kept separate from the
> LSM_ATTR_CLONE_NEWLSM flag because the behaviors are quite different:
> one creates a process with a new LSM namespace set, while the other
> changes the LSM namespace set of a running process.
>
> LSMs are free to implement support for either LSM_ATTR flag, both, or
> none at all.

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, versus having to wait until a later
clone/unshare call and decipher whether any failure is due to the
unsharing of the LSM namespace or something else,
2. Immediately unsharing the namespace upon lsm_set_self_attr() allows
the caller to perform the operation in any desired order relative to
creating a new process or unsharing other namespaces via explicit
ordering of the call with other clone or unshare calls, providing
maximal flexibility/control,
3. We don't need to introduce a new CLONE_* flag at all or introduce
new or changed LSM hooks to clone/unshare,
4. Implementing unshare-like behavior was in fact quite simple for
SELinux namespaces and no more complex than doing so at clone time,
4. Any perceived atomicity benefits of delaying the operation until
the next clone/unshare system call and doing it at the same time as
creating a new process or unsharing another namespace are unclear -
unless we were to change unshare/clone to completely rollback all
changes if any of them fail, they won't actually be atomic and
unshare/clone could fail with an intermediate state left behind.

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.

> * /proc/pid/ns/lsm and setns(CLONE_NEWLSM)
>
> The /proc/pid/ns/lsm file serves as a link/handle to the specific LSM
> namespace set in use for the given process.  A process wishing to move
> into the same LSM namespace set as another process can use this
> link/handle (or a pidfd) and setns(CLONE_NEWLSM) to change its own LSM
> namespace set.  It is important to note that using setns() it should
> not be possible to change the individual LSMs that are part of the LSM
> namespace set, the calling process' LSM namespace is set to the exact
> same LSM namespace set as the specified process.
>
> Affected LSMs may choose to enforce access controls on the
> setns(CLONE_NEWLSM) operation according to their own policy.
>
> * Policy considerations
>
> The mechanisms above provide for three different scenarios: a new
> process creating a new LSM namespace set (the clone case), an existing
> process creating a new LSM namespace set (the unshare case), and an
> existing process joining an existing LSM namespace set (the setns
> case).
>
> In the clone case a new LSM namespace set will be created when the
> process itself is created.  It is up to the individual LSMs to
> properly initialize their own namespaces and load any required
> policies.  Since the new LSM namespaces are created at clone() time
> and before exec(), the calling process, or another trusted process
> using a new yet-to-be-finalized API, should be able to configure the
> newly created LSM namespace before exec().
>
> The unshare case is similar to clone because a new LSM namespace set
> is created, but it is a bit more challenging because unshare()
> modifies the calling process's LSM namespace set, not a newly created
> child process'.  For simpler LSMs this might not pose a problem, but
> for more complex LSMs, developing meaningful applications that use
> unshare(CLONE_NEWLSM) and properly initialize/setup the new LSM
> namespace set may prove challenging. Developing applications that use
> clone(CLONE_NEWLSM) will likely be much easier.
>
> In the setns case the process joins a properly configured LSM
> namespace set with all necessary LSM policies loaded, there shouldn't
> be any additional LSM setup required (although the work to change the
> individual LSM namespaces on a running process may prove difficult).
>
> --
> paul-moore.com