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

[Paul Moore]

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

-- 
paul-moore.com