LSM namespacing API

[Paul Moore]

On Wed, Aug 20, 2025 at 10:44 AM Mickaël Salaün <mic at digikod.net> wrote:
> On Tue, Aug 19, 2025 at 02:51:00PM -0400, Paul Moore wrote:
> > On Tue, Aug 19, 2025 at 1:47 PM Stephen Smalley
> > <stephen.smalley.work at gmail.com> wrote:

...

> > Since we have an existing LSM namespace combination, with processes
> > running inside of it, it might be sufficient to simply support moving
> > into an existing LSM namespace set with setns(2) using only a pidfd
> > and a new CLONE_LSMNS flag (or similar, upstream might want this as
> > CLONE_NEWLSM).  This would simply set the LSM namespace set for the
>
> Bike shedding but, I would prefer CLONE_NEWSEC or something without LSM
> because the goal is not to add a new LSM but a new "security" namespace.

I disagree with your statement about the goal.  In fact I would argue
that one of the goals is to explicitly *not* create a generic
"security" namespace.  Defining a single, LSM-wide namespace, is
already an almost impossible task, extending it to become a generic
"security" namespace seems maddening.

> > setns(2) caller to match that of the target pidfd.  We still wouldn't
> > want to support CLONE_LSMNS/CLONE_NEWLSM for clone*().
>
> Why making clone*() support this flag would be an issue?

With the understanding that I'm not going to support a single LSM-wide
namespace (see my previous comments), we would need multiple flags for
clone*(), one for each LSM that wanted to implement a namespace.
While clone3() has expanded the number of flag bits from clone(),
there is still a limitation of 64-bits and I'm fairly certain the
other kernel devs are not going to be supportive of a flag for each
LSM that wants one.

Maybe we could argue for our own u64 in cl_args, or create our own
lsm_clone(2) syscall that mimics clone3(2) with better LSM support,
but neither of these seem like great ideas at the moment.

> > Any other ideas?
>
> The goal of a namespace is to configure absolute references (e.g. file
> path, network address, PID, time).  I think it would make sense to have
> an LSM/MAC/SEC namespace that would enforce a consistent access control
> on every processes in this namespace.

Once again, I'm not going to support the idea of a namespace at the
LSM framework layer, individual LSMs are better suited to implementing
their own namespacing concepts.  However, I do support the LSM
framework providing an API and/or helpers to help make it easier for
individual LSMs and userspace to create/manage individual LSM
namespaces.

> A related namespace file
> descriptor could then be used with an LSM-specific syscall to configure
> the policy related to a specific namespace (instead of only the current
> namespace)

That is a reasonable request, and I think the same underlying solution
that we would use for setns(2) could also be used here.

--
paul-moore.com