Re: 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 5:10 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> On Sun, Sep 13, 2026 at 7:25 PM Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> > On Sun, Sep 13, 2026 at 12:41 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > > On Sat, Sep 12, 2026 at 3:33 PM Alexei Starovoitov
> > > <alexei.starovoitov@xxxxxxxxx> 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@xxxxxxxxxxxx/
> >
> > And that's an example of unacceptable land grab by LSM folks
> > that I'm concerned about.
>
> I made sure that patchset was ACK'd or Reviewed-by'd a VFS maintainer,
> a BPF LSM maintainer, and the Smack maintainer before merging (I
> covered the LSM and SELinux parts).  You might want to double check
> your definition of "land grab".

You're still missing the point.
Christian could have landed it via vfs tree with your ack for security/*.
You have no power over lsm hook changes within vfs.