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

[Paul Moore]

On Wed, Aug 5, 2026 at 8:32 PM Justin Suess <utilityemal77@xxxxxxxxx> wrote:
> On Wed, Aug 05, 2026 at 06:51:56PM -0400, Paul Moore wrote:
> > On Wed, Aug 5, 2026 at 5:37 PM Justin Suess <utilityemal77@xxxxxxxxx> 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 <utilityemal77@xxxxxxxxx> 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.

Not exactly.  That "bpf_*landlock*_XXX" kfuncs are a move away from an
LSM agnostic API and not something we currently do in the kernel.
Some will, and have, argued that this is more akin to the Landlock
syscalls, but I see (at least) two problems with that comparison: the
kfuncs being presented aren't syscalls, they are cross-subsystem
kernel function calls; the Landlock syscalls were created in a
different time, today these would need to be reframed as LSM
syscalls*.

(* To be clear, we're not going to remove the Landlock syscalls for
all the obvious reasons, but we're also not going to support APIs like
that unless we have throughly exhausted all other options.)

-- 
paul-moore.com