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

[Paul Moore]

On February 17, 2026 9:54:42 AM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> On Mon, Feb 16, 2026 at 07:53:11PM +0100, Paul Moore wrote:
> > On February 16, 2026 2:52:34 PM Christian Brauner <brauner@xxxxxxxxxx> 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.
> > >
> > > Add a ns_security pointer to ns_common and the corresponding lbs_ns
> > > blob size to lsm_blob_sizes. Allocation and freeing hooks are called
> > > from the common __ns_common_init() and __ns_common_free() paths so
> > > every namespace type gets covered in one go. All information about the
> > > namespace type and the appropriate casting helpers to get at the
> > > containing namespace are available via ns_common making it
> > > straightforward for LSMs to differentiate when they need to.
> > >
> > > A namespace_install hook is called from validate_ns() during setns(2)
> > > giving LSMs a chance to enforce policy on namespace transitions.
> > >
> > > Individual namespace types can still have their own specialized security
> > > hooks when needed. This is just the common baseline that makes it easy
> > > to track and manage namespaces from the security side without requiring
> > > every namespace type to reinvent the wheel.
> > >
> > > Signed-off-by: Christian Brauner <brauner@xxxxxxxxxx>
> > > ---
> > > include/linux/lsm_hook_defs.h      |  3 ++
> > > include/linux/lsm_hooks.h          |  1 +
> > > include/linux/ns/ns_common_types.h |  3 ++
> > > include/linux/security.h           | 20 ++++++++++
> > > kernel/nscommon.c                  | 12 ++++++
> > > kernel/nsproxy.c                   |  8 +++-
> > > security/lsm_init.c                |  2 +
> > > security/security.c                | 76 ++++++++++++++++++++++++++++++++++++++
> > > 8 files changed, 124 insertions(+), 1 deletion(-)
> >
> > I still have limited network access for a few more days, but a couple of
> > quick comments in no particular order ...
> >
> > Generally speaking we don't add things to the LSM interface without a user,
> > and I can't think of a good reason why we would want to do things
> > differently here.  This means that when you propose something like this you
> > should also propose an addition to one of the in-tree LSMs to make use of
> > it. While the guidance doc linked below (also linked in the LSM MAINTAINERS
> > entry) doesn't have any guidance for the LSM blobs as they are generally a
> > byproduct of the hooks, if you are looking for some general info I think the
> > bits on adding a new LSM hook would be very close to what we would expect
> > for blob additions.
> >
> > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md
> >
> > Getting to the specifics of namespace related APIs, we've had a lot of
> > discussions about namespacing and my current opinion is that we need to sort
> > out if we want a userspace API at the LSM framework layer, or if we want to
> > do that at the individual LSM layer; there is a lot of nuance there and
> > while one option may seem like an obvious choice, we need some more
> > discussion and I need a chance to get caught up on the threads. Once we have
> > an API decision then we can start sorting out the implementation details
> > like the LSM blobs.
>
> I might be misunderstanding you but what you are talking about seems
> namespacing the LSM layer itself.
>
> But I cannot stress enough this is not at all what this patchset is
> doing. :)

Likely also a misunderstanding on my end as I triage email/patches via phone.

Regardless, the guidance in the doc I linked regarding the addition of new 
LSM hooks would appear to apply here.

--
paul-moore.com