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

[Alexei Starovoitov]

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.

> 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
just use bpf-lsm and implement whatever policy you need there.
If bpf-lsm is missing a feature we can fix that.

selinux/landlock shouldn't be calling into bpf
and bpf shouldn't be calling into selinux/landlock internals.