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

[Justin Suess <utilityemal77@gmail.com>]

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@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.
>

I would raise bpf_ima_file_hash, bpf_ima_inode_hash, as examples of
clear precedence for this. (BPF calling into specific LSM)

Is this also discouraged now?

These IMA BPF functions are also helpers, which are more "permanent"
than the kfuncs like this patch proposes.

Kfuncs are explicitly marked as not being an ABI, and are more
flexible for later changes / deprecation etc. [1]

That was partially why I proposed this as a kfunc, and not a helper.

[1] : https://docs.ebpf.io/linux/concepts/kfuncs/

> Yes, Landlock does have its own syscalls, but those are
> "grandfathered" and not something I want to see emulated across other
> LSMs.  If a BPF program wants to interact with a LSM, it should go
> through a LSM framework API.
>

LSM framework API can mean a lot of things. I assume you are meaning
like a pseudo-filesystem mounted interface that controls LSM? 
Correct me if I'm wrong.

I'm a little unsure how this would work with the BPF model. Generally,
BPF relies on type checking and reference checking. Creating a weakly
typed securityfs / sysfs like interface would be very awkward for BPF to
use. Especially if it requires reading / writing files, or parsing
strings, it would be very hairy. It's the same problem with reading any
file from kernel space, it's almost always inadvisable.

Pseudo-fs is fantastic for userspace, (read and write is as simple as
echo and cat) but not fantastic when you are writing BPF programs.

But maybe this is a false diochotomy, I see no reason why the LSM
framework API couldn't have a strongly typed interface into BPF via
helpers / kfuncs. In that case, wouldn't these kfuncs be exactly that
LSM framework API? And there be some translation layer exposing them to
userspace using BTF type information -> pseudo fs? :)

BTF is not just for BPF!

Justin

> There have been some initial efforts to develop a LSM wide policy API
> for userspace, and while it was put on hold to sort out some namespace
> issues, we could move forward with an in-kernel API now.  We don't
> have strict API stability guarantees for LSM hooks/APIs so we have
> some more freedom to do something now, even if it isn't perfect, and
> refine it at a later date.
> 
> -- 
> paul-moore.com