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

[Paul Moore]

On February 16, 2026 2:52:34 PM Christian Brauner <brauner at kernel.org> 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 at kernel.org>
> ---
> 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.

--
paul-moore.com
>