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

["Dr. Greg" <greg@enjellic.com>]

On Sun, Sep 13, 2026 at 07:24:14PM -0700, Alexei Starovoitov wrote:

> On Sun, Sep 13, 2026 at 5:10???PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Sun, Sep 13, 2026 at 7:25???PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > > On Sun, Sep 13, 2026 at 12:41???PM Paul Moore <paul@paul-moore.com> wrote:
> > > > On Sat, Sep 12, 2026 at 3:33???PM Alexei Starovoitov
> > > > <alexei.starovoitov@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.
> >
> > 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.

I've indicated to a number of colleagues that this issue would begin
to generate considerable dialogue, once everyone finished with their
summer holidays, I see that fact is now eventuating.

There is an important discussion to be had that affects the ability of
Linux to serve the security needs of its constituency, which at this
point now, is pretty much the planet and beyond.  Advancing a relevant
discussion requires casting the underlying issue involved in all of
this into perhaps the glow of harsh sunlight.

The issue at hand is not who gets to ACK or NACK various security
relevant infrastructure, based on who manages source code in a
particular directory heirarchy.

The underlying motivation driving all of this is who gets to control
and define what can be advertised as 'mainline' Linux security.  This
has been the bane of Linux security development for a quarter century
now, Linus openly acknowledges this fact, ie. security people can
never agree on how to do things.

Given the power that this control conveys on certain parties, the
objective of maintaining this type of control is certainly
understandable.

I have deep respect for Linus, but he has failed to demonstrate
appropriate leadership on this front.  Indicating that people should
simply figure out how to use what is already in Linux, given the
current technological tsunami of machine modeling/learning overtaking
all of us, is so hopelessly naive that I cannot believe that he
actually believes what he is saying.

The current static security architectures in Linux, supported by the
LSM model and its development processes, while still technically
useful, will not be operationally relevant to the technology industry
by the end of the decade.

We need a technical architecture to fix to what is a political
problem.  That seems consistent with Linux development ostensibly
being about technology rather than politics.

The steps in recovery are admitting, and then identifying, that one
has a problem, before it can be fixed.  Given the agendas involved it
seems like a great role for the Linux Foundation to assist with.

We now return you to your regularily scheduled programming of who gets
to ACK/NACK kfuncs.

Greg

My opinions and those of my Golden Retriever Hezzie only.