[RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs

[Paul Moore]

On Wed, Jul 1, 2026 at 3:49 PM Mickaël Salaün <mic at digikod.net> wrote:
> On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> > On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic at digikod.net> wrote:
> > > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77 at gmail.com> wrote:
> > > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic at digikod.net> 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.
> > >
> > > This patch series is not about the LSM framework, only about Landlock
> > > and its specific model and use case.  Landlock using some of the LSM API
> > > is not relevant here.
> >
> > Based on a quick look the patchset enables BPF programs to call
> > directly into Landlock.  For the same reason we discourage other parts
> > of the kernel to call directly into individual LSMs, we want to
> > discourage BPF programs from calling directly into individual LSMs.
>
> We're OK for a dedicated kfunc to call directly into Landlock (with a
> tailored interface).  Landlock is designed around its syscall interfaces
> (well documented, tailored, tested), and this would be a new user of
> almost the same UAPI.

Larger issues exist beyond the suitability of Landlock's API; in fact
Landlock's API isn't really the issue as far as I'm concerned.  The
issue is that we don't want the kernel, whether via C code or BPF
code, calling directly into individual LSMs.  We don't even support
LSM A calling directly into LSM B.  Any caller making a call into an
LSM really needs to do so through an LSM hook.

I'm not opposed to allowing BPF code to call into Landlock, it just
needs to do so through an LSM hook like everything else to date.

-- 
paul-moore.com