Re: [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 08:20:41PM -0400, Justin Suess wrote:

> On Sat, Sep 12, 2026 at 12:33:13PM -0700, Alexei Starovoitov 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.
> > kfuncs are not stable. we keep refactoring them.
> > while lsm folks treat anything within *lsm* and *security* as stable apis.
> > So any kfunc where they have a say, will become a huge burden for further
> > bpf development.

> There are patches on the front page of 
> lore.kernel.org/linux-security-module refactoring security
> hooks and changing signatures. Security hooks and the LSM interface
> is not stable, this is explicitly documented. 
> I deliberately chose kfuncs over helpers to avoid having the interface
> be ossified.

> > > Where would you point me to?
> > 
> > landlock was designed for unprivileged users. bpf needs CAP_BPF.
> > There is a fundamental disconnect. If you can tolerate CAP_BPF then

> Landlock is for privileged and unprivileged users alike.
> This patchset is designed to compose with unprivileged use seamlessly,
> which works because of Landlock's monotonicity.

> > just use bpf-lsm and implement whatever policy you need there.
> > If bpf-lsm is missing a feature we can fix that.

> Sure, in some perfect world in the future where every verifier
> challenge is solved and BPF has feature parity with in-tree c on
> a 1:1 basis, you could implement something like SELinux, or Landlock
> in pure eBPF. It would be about as easy and trivial as building a
> skyscraper from lego bricks.
> 
> There is an entire in-tree ecosystem of LSMs that would provide
> BPF users with well-maintained, versioned, and tested access
> control. Why force every eBPF program that needs to make security
> decisions to reeinvent the wheel? 
> 
> There are real eBPF users such as Tetragon, Falco, Tracee, that
> could use an actively maintained implementation of security models that
> exist in-tree in security/. This would make access control in eBPF much
> less painful.
> 
> Instead of implementing every filesystem, network, and 
> socket access control, they can use existing solutions, and with
> the userspace tooling that already exists. And they can
> mix-and-match, doing custom logic/policy in BPF, and use what
> they need in LSM, with BPF making policy decisions.
> 
> It would fix a real challenge that users have with eBPF, and wouldn't
> take away from BPF's ability to do what it already does.

Justin, I find your thoughts and perspective on this interesting.

First a general question:

If we understand correctly, your work is to enhance the capabilities
of LandLock.  You are fortunate to be in the kernel already and you
have at least a system call interface as a control plane and of course
the possibility of implementing a pseudo-filesystem interface if
something beyond the system call interface was needed.

Given that, what is the motivation for bringing eBPF and all the
assorted drama related to that into the picture?

In addition to all the political drama, eBPF signing is still a bit up
in the air as is the ability to completely lock eBPF based policy into
the kernel so an adversary cannot displace it.

The other issue with this work, seems best described as a problem of
'Mixing of the Blood', as it was once referred to in the Iron Triangle
country of south central North Dakota.

This effort seeks to merge two diametrically opposed viewpoints on how
Linux security should be implemented.  The camp that believes that all
security policy should only be implemented, and most importantly,
controlled through requiring inclusion in the kernel and the camp
seeking the ability to implement kernel based security policies
without years of contentious political struggle.

You raise the question above of as to why we should be forcing every
eBPF program developer to dump out a pile of Lego's and start stacking
them.  The reason is simple, it is the only way to move forward,
particularily in a timely manner, given how fast the security
landscape and challenges are advancing.

While work like this could undoubtedly benefit the Tetragon, Falco,
Tracee and others of this world it seems likely to run into issues
over whether policy should be in the hands of what amounts to
userspace.

> Thanks,
> Justin

Thanks for any insight you may have, especially with respect to the
advantages of endowing in tree LSM's with eBPF capabilities.

Have a good remainder of the week.

Greg