Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
Paul Moore <[email protected]>
| Newsgroups | org.kernel.vger.linux-security-module,org.kernel.vger.bpf,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAHC9VhRfqSoM89WC6TdQHapUVQe8a18rW2c-F7+tu6EjM9EdCA@mail.gmail.com> |
On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <[email protected]> wrote: > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote: > > Create 2 kfuncs exposing control over Landlock functionality to BPF > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers > > from accessing unstable internal Landlock fields. Generally speaking we don't want to provide APIs, either in-kernel or at the userspace/kernel boundary, that are specific to a single LSM, see the LSM syscalls or the security_current_getlsmprop_subj() function as examples. Yes, Landlock does have its own syscalls, but those are "grandfathered" and not something I want to see emulated across other LSMs. If a BPF program wants to interact with a LSM, it should go through a LSM framework API. There have been some initial efforts to develop a LSM wide policy API for userspace, and while it was put on hold to sort out some namespace issues, we could move forward with an in-kernel API now. We don't have strict API stability guarantees for LSM hooks/APIs so we have some more freedom to do something now, even if it isn't perfect, and refine it at a later date. -- paul-moore.com