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

On Wed, Jul 1, 2026 at 3:55 PM Justin Suess <[email protected]> wrote:
> On Wed, Jul 01, 2026 at 09:49:07PM +0200, Mickaël Salaün 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 <[email protected]> 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 <[email protected]> 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 <[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.
> > > >
> > > > 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.
>
> Paul, Mickaël,
>
> I think there's a cleaner way to resolve this.
>
> First, walking back my earlier email: I was wrong saying that we need to call
> into security/security.c to check whether Landlock is enabled. Landlock's
> init only runs when it's in the active lsm= list, so I can just test
> landlock_initialized directly. There's no per-invocation reason to route
> through the LSM framework for that.

The landlock_initialized flag is not really a LSM framework API, that
is still Landlock specific which is something we try hard to avoid.

> Rather than routing each kfunc *invocation* through a security/security.c
> wrapper, I think the right place for the framework to be involved is
> *registration*: have the LSM framework own registration of an LSM's
> kfunc sets, e.g.
>
>     int security_register_lsm_kfunc_set(u64 lsm_id, enum bpf_prog_type type,
>                                         const struct btf_kfunc_id_set *kset);

That implies a set of LSM kfunc APIs which Alexei has been deadset
against (see other ongoing threads).

> Each LSM calls this once to register its sets. Because registration goes
> through the framework, the framework gets to decide whether to actually
> register them so you could, for example, run an LSM while explicitly
> opting its BPF kfuncs out. (something that should be done at the LSM
> framework level).

I'm not opposed to the LSM supporting a set of kfuncs, see my comments
in other threads, but we should treat these kfuncs just as we treat
other LSM hooks today because that is what they are: LSM hooks that
happened to be called from within a BPF program.

-- 
paul-moore.com