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

[Mickaël Salaün]

On Wed, Jul 01, 2026 at 02:41:49PM -0700, Casey Schaufler wrote:
> On 7/1/2026 1:02 PM, Paul Moore wrote:
> > ...
> >
> >> 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.
> 
> As someone who has been working to get the SELinux specific assumptions
> out of the LSM framework for the past 15 years the notion of adding
> Landlock specific interfaces makes me want to cry. Is it really that
> difficult to understand that 5 or 10 years from now something is going
> to come along that makes any LSM specific interface a nightmare?

>From my point of view, your work has been, and continue to be, very
valuable and helped improve Linux security tremendously.  Everyone agree
that no LSM should implement their own security hook.  But that's not
the topic here.  See
https://lore.kernel.org/all/20260701.aeghohNoe3ek@digikod.net/

> What
> if there's an LSM that does what Landlock does, but does it better?

Then the eBPF programs will use another kfunc, specific to the *new*
semantic of the other LSM.

> What if the Landlock sponsors decide to quit funding it? Or the maintainers
> get bored?

It is the same for any (kernel) interface: going through a multiplexer
would not help at all.  Your argument is sound for security hooks, but
not here.  Security (or access control) hooks make sense because they
identify a set of specific enforcement points in the kernel, and any LSM
can implement such hook to allow or deny the related operation.  Other
hooks are useful to keep track of the kernel state.  Again, see
https://lore.kernel.org/all/20260701.aeghohNoe3ek@digikod.net/

> 
> I agree with Paul completely. Make the hooks available to any and all
> LSMs, or don't make them at all.

We don't need a security hook but a function call to one specific part
of the kernel with a very clear semantic that only make sense for one
subsystem (i.e. Landlock in this case).  It's the same for other kfunc,
nothing special.  The same way it would be a waste of time to implement
an in-kernel multiplexer for a set of unrelated operations, I really
don't see the value of adding a generic kfunc that might perform an
action according to an operation argument (i.e. multiplexer).  Why
implementing an ioctl-like interface in the kernel?  I'm open to
suggestions (and concrete proposal/examples) but so far I only heard
authoritative arguments that ignored most of my comments.