Re: [PATCH bpf-next 00/13] BPF interface for applying Landlock rulesets

On Wed, Aug 05, 2026 at 06:51:56PM -0400, Paul Moore wrote:
> On Wed, Aug 5, 2026 at 5:37 PM Justin Suess <[email protected]> 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?
> >
> > 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.
> 
> This gets back to the other issue in the patchset that we've
> discussed: general LSM interfaces vs Landlock specific interfaces.
> There are plenty of reasons why we don't support the kernel calling
> directly into individual LSMs, and from my perspective this is another

I'm 100% on board with the no calling directly into individual LSMs part.

> instance of that.  Here it just happens to be that the kernel caller
> was written in BPF and not C (or Rust for that matter).

The intention is the opposite. The point of the separate directory is
that the kfuncs can never call into an individual LSM, they only get
the LSM framework API in <linux/security.h>.

Every kfunc is a thin wrapper over the generic policy kptr hooks:

    bpf_landlock_get_ruleset_from_fd()
      -> security_policy_kptr_from_fd(LSM_ID_LANDLOCK, ...)
        -> Landlock's hook implementation

So kfunc -> generic lsm hook -> individual LSM, same as any other
caller in the kernel. There's no build dependency on Landlock either:
the kfuncs register under CONFIG_BPF_LSM, and if Landlock is compiled
out or not in the lsm order, the hook dispatch by lsm id misses and
the call returns -EOPNOTSUPP.

The only Landlock-specific part is what the BPF program sees: the
kfunc names and the opaque handle (an empty struct
bpf_landlock_ruleset).

Permit me to use SELinux-specific interface through LSM as an example.

The existing userspace API already has this exact pattern (partially
from [1], thanks Casey it was a great talk!):

  ctx->id      = LSM_ID_SELINUX;
  ctx->flags   = 0;
  ctx->len     = sizeof(struct lsm_ctx) + ctx_len;  
  ctx->ctx_len = ctx_len;
  memcpy(ctx->ctx, "unconfined_u:unconfined_r:foo_t:s0", ctx_len);

  lsm_set_self_attr(LSM_ATTR_EXEC, ctx, ctx->len, 0);

If you think about it; that's what this patch is doing!
"unconfined_u:unconfined_r:foo_t:s0" is as LSM specific as
bpf_landlock_ruleset* is.

This is a generic framework syscall, targeted at one LSM by lsm id, carrying
an LSM-specific payload. Our kptr is basically the lsm_ctx; the
difference is that the lsm id and payload type move out of runtime
fields and into the BTF type, so a mismatch fails at program load
instead of at runtime. Much better for security! (fail fast and fail
hard)

The verifier is why the lsm id can't stay runtime data the way
lsm_ctx carries it. Say LSM xyz's policy struct is protected by a
mutex (the caller must be able to sleep) while LSM abc's is accessed
under RCU. Those rules are enforced at program load time through the
KF_* annotations and argument types of the kfunc itself, so a single
generic policy kfunc can't carry both. Per-LSM kfuncs above the
generic hooks are what let the verifier *prove* each LSM's objects are
only accessed in the right context.

Userspace only gets away with the fully generic lsm_ctx because its
calling context is always the same: syscall context. BPF programs are
everywhere from syscalls to LSM hooks, so the context requirements
have to be part of the interface.

So I don't see these kfuncs as a Landlock-specific interface. They're
the same generic interface the framework already gives userspace,
with the lsm id and access rules promoted into *types* the verifier
can check at load time.

Justin

[1] https://static.sched.com/hosted_files/lssna24/1a/2024-04-LSSNA-liblsm.pdf