Re: [PATCH 1/4] ns: add bpf hooks

[Christian Brauner]

On Tue, Feb 24, 2026 at 01:35:11PM +0000, Matt Bobrowski wrote:
> On Fri, Feb 20, 2026 at 01:38:29AM +0100, Christian Brauner wrote:
> > Add the three namespace lifecycle hooks and make them available to bpf
> > lsm program types. This allows bpf to supervise namespace creation. I'm
> > in the process of adding various "universal truth" bpf programs to
> > systemd that will make use of this. This e.g., allows to lock in a
> > program into a given set of namespaces.
> > 
> > Signed-off-by: Christian Brauner <brauner@xxxxxxxxxx>
> > ---
> >  include/linux/bpf_lsm.h | 21 +++++++++++++++++++++
> >  kernel/bpf/bpf_lsm.c    | 25 +++++++++++++++++++++++++
> >  kernel/nscommon.c       |  9 ++++++++-
> >  kernel/nsproxy.c        |  7 +++++++
> >  4 files changed, 61 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/bpf_lsm.h b/include/linux/bpf_lsm.h
> > index 643809cc78c3..5ae438fdf567 100644
> > --- a/include/linux/bpf_lsm.h
> > +++ b/include/linux/bpf_lsm.h
> > @@ -12,6 +12,9 @@
> >  #include <linux/bpf_verifier.h>
> >  #include <linux/lsm_hooks.h>
> >  
> > +struct ns_common;
> > +struct nsset;
> > +
> >  #ifdef CONFIG_BPF_LSM
> >  
> >  #define LSM_HOOK(RET, DEFAULT, NAME, ...) \
> > @@ -48,6 +51,11 @@ void bpf_lsm_find_cgroup_shim(const struct bpf_prog *prog, bpf_func_t *bpf_func)
> >  
> >  int bpf_lsm_get_retval_range(const struct bpf_prog *prog,
> >  			     struct bpf_retval_range *range);
> > +
> > +int bpf_lsm_namespace_alloc(struct ns_common *ns);
> > +void bpf_lsm_namespace_free(struct ns_common *ns);
> > +int bpf_lsm_namespace_install(struct nsset *nsset, struct ns_common *ns);
> > +
> >  int bpf_set_dentry_xattr_locked(struct dentry *dentry, const char *name__str,
> >  				const struct bpf_dynptr *value_p, int flags);
> >  int bpf_remove_dentry_xattr_locked(struct dentry *dentry, const char *name__str);
> > @@ -104,6 +112,19 @@ static inline bool bpf_lsm_has_d_inode_locked(const struct bpf_prog *prog)
> >  {
> >  	return false;
> >  }
> > +
> > +static inline int bpf_lsm_namespace_alloc(struct ns_common *ns)
> > +{
> > +	return 0;
> > +}
> > +static inline void bpf_lsm_namespace_free(struct ns_common *ns)
> > +{
> > +}
> > +static inline int bpf_lsm_namespace_install(struct nsset *nsset,
> > +					    struct ns_common *ns)
> > +{
> > +	return 0;
> > +}
> >  #endif /* CONFIG_BPF_LSM */
> >  
> >  #endif /* _LINUX_BPF_LSM_H */
> > diff --git a/kernel/bpf/bpf_lsm.c b/kernel/bpf/bpf_lsm.c
> > index 0c4a0c8e6f70..f6378db46220 100644
> > --- a/kernel/bpf/bpf_lsm.c
> > +++ b/kernel/bpf/bpf_lsm.c
> > @@ -30,10 +30,32 @@ __weak noinline RET bpf_lsm_##NAME(__VA_ARGS__)	\
> >  #include <linux/lsm_hook_defs.h>
> >  #undef LSM_HOOK
> >  
> > +__bpf_hook_start();
> > +
> > +__weak noinline int bpf_lsm_namespace_alloc(struct ns_common *ns)
> > +{
> > +	return 0;
> > +}
> > +
> > +__weak noinline void bpf_lsm_namespace_free(struct ns_common *ns)
> > +{
> > +}
> 
> I'm wondering how you foresee this hook functioning in a scenario
> where the BPF LSM program is attached to this new hook point, although
> with its attachment type being set to BPF_LSM_CGROUP instead of
> BPF_LSM_MAC? You probably wouldn't want to utilize something like
> BPF_LSM_CGROUP for your specific use case, but as things stand
> currently I don't believe there's anyhthing preventing you from using
> BPF_LSM_CGROUP with a hook like bpf_lsm_namespace_free().

Oh, I very much would like this to be attachable to cgroups.

> Notably, the BPF_LSM_CGROUP infrastructure is designed to execute BPF
> programs based on the cgroup of the currently executing task. There
> could be some surprises if the bpf_lsm_namespace_free() hook were to
> ever be called from a context (e.g, kworker) other than the one
> specified whilst attaching the BPF LSM program with type
> BPF_LSM_CGROUP.

But isn't this then a generic problem? What about:

# RCU callbacks
security_cred_free
security_task_free
security_inode_free_security_rcu
security_bpf_prog_free
security_xfrm_policy_free_security
security_msg_queue_free_security
security_shm_free_security
security_sem_free_security
security_audit_rule_free
security_bdev_free_security
security_sk_free_security

# Workqueues
security_bpf_map_free
security_bpf_token_free
security_sb_free_security
security_file_free_security
security_file_release
security_xfrm_state_free_security

ignoring sofirq/hardirq for now.

So the only real problem I can see is that someone wants to do something
from a *_free() hook that isn't actually freeing but actual policy based
on the cgroup of @current? I find that hard to believe tbh. Fwiw,
bpf_lsm_namespace_free() is classified as untrusted because at that
point the outer namespace might already be blown away partially.
Effectively alloc() and free() hooks are mostly notification mechanisms
of creation/destructions. If you want to do actual policy you might have
to defer it until an actual operation is done.