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

On Wed, Jul 1, 2026 at 5:28 PM Mickaël Salaün <[email protected]> wrote:
> On Wed, Jul 01, 2026 at 04:02:36PM -0400, Paul Moore wrote:
> > 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.
>
> What an LSM hook is or should be is the crux of the misunderstanding.  I
> explained my point of view here:
> https://lore.kernel.org/all/[email protected]/
>
>   LSM hooks make sense because they are designed for a specific subsystem
>   (the caller) and their goal is to return an access decision or to keep
>   up-to-date related states, which means that their API is designed for
>   the caller, with its own types and specificities, not the other way
>   around.  This case is different, the kfunc is strongly typed and tied to
>   the Landlock (subsystem) semantic with an API defined by and for
>   Landlock.  I don't think a multiplexer would be a good idea.
>
> I'd try to explain better: in a nutshell, an LSM hook exposes a subset
> of the context of the caller, for any access control system to be able
> to make a decision.

That is true for some LSM hooks, but not all of them.  LSM hooks are
really just another name for the functions that compose parts of the
LSM framework API; it isn't always strictly about access control in
the kernel.  We leverage the "hooks" for the LSM syscalls, we've
discussed "hooks" for implementing a common LSM namespace API, and
there have also been early efforts at LSM policy loading via "hooks".

> It makes sense to have such dispatcher because the
> callees must adapt to the caller's context, and then the API is tailored
> to the caller, so even with several consumers, the API would ultimately
> be the same.  In the case of this kfunc, the callee is one specific
> subsystem that happens to be Landlock.  The caller asks a specific
> subsystem to do something specific to this subsystem, not to ask all
> potential access control systems to give a generic verdict to grant an
> access or not.

> For this kfunc, the caller passes arguments which are
> specific to the callee subsystem (e.g. a Landlock ruleset), not the
> other way around.  Every LSM has its own configuration, and it doesn't
> make sense to somehow wrap these configurations with a common layer/API.

Once again, there have already been discussions about trying to build
a common API for that.  I'd rather have us pick that up for an
in-kernel/kfunc users than treat Landlock as an exception.  We're
trying to get rid of the exceptions in the LSM space.

> Why not start with something simple that fits a use case now?  If and
> when another LSM will need a kfunc, then we'll have something concrete
> to talk about.

I think Casey's reply answers that question rather well.

-- 
paul-moore.com