Re: [PATCH bpf-next 00/13] BPF interface for applying Landlock rulesets
Justin Suess <[email protected]>
| Newsgroups | org.kernel.vger.linux-security-module,org.kernel.vger.bpf,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <anOvpFMIuwNqDHfA@zenbox> |
On Wed, Aug 05, 2026 at 05:37:07PM -0400, Justin Suess wrote: > On Fri, Jul 31, 2026 at 04:30:39PM -0400, Paul Moore wrote: > > On Thu, Jul 30, 2026 at 10:21 PM Justin Suess <[email protected]> wrote: > > [...] > > As you may, or may not have seen, there is currently an ongoing debate > > regarding the location of LSM kfuncs that will impact this patchset. > > Sadly, we don't appear to be approaching an agreement on this issue > > which introduces some additional risk to this patchset. We'll have to > > see how that ends up, but I just wanted you to be aware of the > > situation. > > Quick aside question: Would security/bpf/ be a better place for these > type of kfuncs? > *lsm-specific kfuncs, sorry should have been more clear. Justin > security/bpf/bpf_lsm_kfuncs.c could be for LSM framework kfuncs, > and each LSM could maintain their own security/bpf/<lsm>_kfuncs.c > for kfuncs dealing with lsm-specific types. > > One issue with just security/ is it's not CONFIG_SECURITY_BPF. But > security/bpf is. Right now security/bpf only has hooks.c so it's free > real estate. > > That way things are more greppable... (important!) and we can have > proper MAINTAINERS entries per file so emails get routed properly. > > (linux-security-module, bpf, and whatever lsm list) > > Justin