[PATCH RFC] security: add LSM blob and hooks for namespaces

[Dr. Greg]

On Tue, Feb 17, 2026 at 10:38:33AM +0100, Christian Brauner wrote:

Good morning, I hope the week is going well for everyone.

> On Mon, Feb 16, 2026 at 09:34:57AM -0800, Casey Schaufler wrote:
> > On 2/16/2026 5:52 AM, Christian Brauner wrote:
> > > All namespace types now share the same ns_common infrastructure. Extend
> > > this to include a security blob so LSMs can start managing namespaces
> > > uniformly without having to add one-off hooks or security fields to
> > > every individual namespace type.
> > 
> > The implementation appears sound.
> > 
> > I have to question whether having LSM controls on namespaces is reasonable.

> This is already in active use today but only in a very limited capacity.
> This generalizes it.

This seems to be a tacid indication of the need for namespace specific
LSM policies and/or controls, and further acknowledgement, that such
controls are in active use out in the wild.

More below on the implications of this.

> > I suppose that you could have a system where (for example) SELinux runs
> > in permissive mode except within a specific user namespace, where it would
> > enforce policy. Do you have a use case in mind?

> We will use it in systemd services and containers to monitor and
> supervise namespaces.

Christian, you are no doubt not familiar with our work, but over the
last six years our team has developed and have in production the most
sophisticated implementation of LSM namespacing that has been done.
With the caveat, of course, of implementations that have been made
public.

That work has been driven by what is the clear and apparent need to
have namespace specific and orthogonal security controls and policies,
something your patch and comments seems to clearly acknowledge.  This
need is particularily important with respect to the advancements that
are needed for AI based security modeling and interdiction.

So our comments are driven by having done a bit of this before.

There has been some dialogue and debate as to whether and how LSM
namespacing should be implemented.  The essential ingredient is the
need to have a task specific context of data, which can be inherited
by subordinate processes, that can be used to evaluate the LSM
security events/hooks that are executed by tasks having access to
that context of data.

Unless we misinterpret the implementation, your patch provides such
context for any process that wishes to unshare any namespace that it
is participating in.

This in turn implies that your patch is a fundamental step forward in
LSM namespacing.  This isn't a criticism, just an observation.

The reason we can feel pretty strongly about this is that we initially
used the same strategy that you are using in a very early
implementation of TSEM.  We abandoned that approach, since the
dynamics/politics of Linux kernel development, particularily in
security, tends to disfavor having to touch core kernel
infrastructure, so we implemented the equivalent of your approach
entirely in the context of our LSM.

To widen the scope of the impact of this, your patch also lays the
framework for implementing LSM specific security policy with kernel
modules.  Again, not a criticism, just an observation, because we
implement the same capability with TSEM.

For those reading along at home.  The reason that this is safe with a
classic namespace approach and not with previous 'loadable LSM'
strategies is that a process can verify that a policy module is loaded
and prepared to handle requests to interpret the events, before the
namespace installation/activation that would drive use of the module
actually takes effect.

Your approach is quite generic, which is positive. The open question
is whether or not the strategy is generic enough to handle LSM's that
may have very dynamic and varied requirements with respect to how to
configure the policy that will be implemented for the namespace.

Hopefully all of this will enable further discussions on this issue.

Best wishes for a productive remainder of the week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project