BPF and LSM maintainers clash over Landlock policy kfuncs

A patch series that would let BPF programs apply existing Landlock rulesets at process execution has drawn a sharp split between the BPF and LSM camps, stalling what its author frames as a narrow bridge rather than a new policy engine.

Justin Suess's v3 series, posted to the BPF list, keeps the design of earlier rounds. BPF does not build, inspect, or rewrite Landlock policy. Userspace still creates and validates rulesets through Landlock's normal API. BPF only chooses, from exec-time context, whether a given ruleset should bind before the new program runs its first instruction, closing a race a pure userspace supervisor cannot win. The helpers are cast as LSM-generic policy-object kfuncs; Landlock would be the first provider.

LSM maintainer Paul Moore again asked whether BPF still refuses kfuncs living under security/, in the same pattern as filesystem kfuncs elsewhere. BPF maintainer Alexei Starovoitov answered no, and went further. Subsystems such as filesystem, memory management, and networking, he wrote, use BPF to push policy out of the kernel. LSM developers, in his view, treat BPF as an adversary, treat names under security as stable ABI, and would turn any shared kfuncs into a lasting tax on BPF evolution. He also called out a design mismatch: Landlock targets unprivileged confinement, while BPF requires CAP_BPF. With that capability, he argued, authors should implement policy in BPF LSM directly rather than having BPF call into Landlock or SELinux internals, or the reverse.

Moore rejected the caricature. He pointed to recent LSM work merged specifically to help BPF LSM authors, disputed the claim that LSM material is frozen ABI, and pushed back on the idea that BPF's concerns override how security hooks are shaped. Starovoitov answered that core subsystems decide what they expose to hooks, that LSM review of those call sites is not a veto, and that recent hook-signature expansion was an example of overreach.

Automated review of the series also flagged concrete side effects: deferred ruleset freeing that breaks an existing Landlock free-on-close trace test, and an exec-only staging field that would enlarge every file security blob when BPF LSM is enabled, the common distro configuration. Those are fixable engineering notes. The blocker is the ownership fight: whether Landlock application belongs behind BPF kfuncs in the LSM tree, or whether the two stacks should stay deliberately uncoupled.

Until that is settled, the race the series aims to close remains a userspace problem.