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

[Justin Suess <utilityemal77@gmail.com>]

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.

> 
> and bpf shouldn't be calling into selinux/landlock internals.
>
Agreed. And this patchset doesn't call into landlock, it calls a
security hook. The LSM hook then dispatches to whatever LSM
owns the object.

BPF already calls into LSM through security hooks. This is no
different than bpf_map_create hooks.

Nothing about the way BPF works changes with this patchset.
There's no verifier internal changes. It doesn't call into
BPF internals at all, or define any new core constructs.
It just uses the same kfunc and kptr interface that is available
to everyone else in the kernel. I think this code could even
be written with zero changes in kernel/bpf, or files in
BPF's maintainer's entry, though I'd rather have both subsystems
coordinating and cooperating on the interface.

Thanks for your feedback (genuinely), I hope you know I make these
arguments in good faith even when things seem heated.

Thanks,
Justin