LSM boundaries. Was: [PATCH bpf-next v3 04/15] lsm: Add the bpf_lsm_policy_release kfunc and policy object destructor

[Alexei Starovoitov]

On Sun, Sep 13, 2026 at 12:41 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On Sat, Sep 12, 2026 at 3:33 PM Alexei Starovoitov
> <alexei.starovoitov at gmail.com> wrote:
> > On Fri Sep 11, 2026 at 10:26 PM PDT, Justin Suess wrote:
> > >
> > > If fs/, mm/, drivers/, net/, are permitted to have kfuncs, then why not
> > > security/? kfuncs.rst doesn't seem to forbid this.
> >
> > because fs, mm, net see the value in bpf. bpf helps these subsytems
> > to focus on their core technologies and moves policy decisions out of
> > kernel and into bpf.
> > while lsm people treat bpf as arch-enemy.
>
> It's amusing to read this when just this week we merged a patchset
> into the LSM tree for the benefit of those writing BPF LSMs.  If you
> look at the discussion around patch 2/2 you will even see a reasonable
> exchange between Matt Bobrowski, a BPF LSM maintainer, and me about
> the patch.  Alexei is obviously welcome to his own opinion, but I
> would encourage those reading this thread to look beyond his comments.
>
> https://lore.kernel.org/linux-security-module/20260904-lsm-mount-idmaps-v3-0-920a1963675d@amutable.com/

And that's an example of unacceptable land grab by LSM folks
that I'm concerned about.
security*() calls sprinkled around the kernel are not LSM territory.
It's a decision of subsystem maintainers to pass more or less
objects into lsm hooks.
VFS folks could have decided to pass a subset of the object to
avoid exposing internal details to abusive LSMs or, as in this case,
they decided to pass struct mnt_idmap as well to increase
visibility into vfs operations.

Paul,
it's not your call to ack or nack their decisions.
Your job is to review security/*.c side of changes
and give feedback.

The needs of the kernel subsystem are far greater
than all LSM concerns combined.

Daan's patch:
-int security_inode_create(struct inode *dir, struct dentry *dentry,
umode_t mode);
+int security_inode_create(struct mnt_idmap *idmap, struct inode *dir,
+  struct dentry *dentry, umode_t mode);
 void security_inode_post_create_tmpfile(struct mnt_idmap *idmap,
  struct inode *inode);
-int security_inode_link(struct dentry *old_dentry, struct inode *dir,
- struct dentry *new_dentry);
+int security_inode_link(struct mnt_idmap *idmap, struct dentry *old_dentry,
+ struct inode *dir, struct dentry *new_dentry);

broke a bunch of production bpf-lsm programs for many companies.
It's annoying, but I cannot complain, since it was VFS
folks' decision to change their hooks.
Pls at least cc bpf at vger next time.
If you didn't mention it we would have found out about
the breakage only during the next merge window.

Anyway, back to LSM's land grab...
Because of LSM people's behavior, networking folks dont
want to add new LSM hooks.
It's really starting to feel that LSM hooks are like
tracepoints of the past.
They could be in the way of subsystem development.
Hence it's important to stress that it's a subsystem
maintainers' decision to shape LSM hooks in their subsystem.
Neither LSM people nor BPF cannot nack VFS's LSM hook changes.