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

[Matt Bobrowski]

On Fri, Feb 27, 2026 at 03:33:21PM +0100, Christian Brauner wrote:
> 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.

I'd need to take a another deep look, but yeah, from what I can tell
this is a broader general issue for BPF LSM programs which happen to
also make use of the BPF_LSM_CGROUP attachment type.

> 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.