LSM namespacing API

[Paul Moore]

On Tue, Aug 19, 2025 at 10:56 AM Paul Moore <paul at paul-moore.com> wrote:
>
> Hello all,
>
> As most of you are likely aware, Stephen Smalley has been working on
> adding namespace support to SELinux, and the work has now progressed
> to the point where a serious discussion on the API is warranted ...

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.

* /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