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

On Thu, Jul 2, 2026 at 5:53 AM Mickaël Salaün <[email protected]> wrote:
> On Wed, Jul 01, 2026 at 07:32:57PM -0400, Paul Moore wrote:
> > 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.
>
> That's why I wrote "in a nutshell".  Concrete examples and the rationale
> for such hooks would help.

See the LSM syscalls and the discussions leading up to them.  See the
LSM namespacing API discussions.  See any of the hooks in
security/security.c that aren't strictly about access control.

> > 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".
>
> All that is doable, my question is: why a kfunc multiplexer?

It's an interface into the LSM subsystem.  Don't think of the LSM hook
interface as an optional, or nice-to-have, it *is* the interface to
the different LSMs.  There are some legacy reasons around
configuration, and some of the userspace APIs (which have been a major
source of problems over the years), but we generally do better when we
find a way to develop a unified interface rather than separate, LSM
specific ones.

I'm not saying we need a LSM version of ioctl(), but we really must
look at developing LSM-wide APIs (yes, that includes kfuncs) first and
only if we are not able to develop a LSM agnostic API then we can
fallback to LSM specific interfaces.

> What are
> the pros and cons?  I only see disadvantages for now.  Please, convince
> us.

This logic is backwards.  Work to develop an LSM interface first, and
then if we are all convinced that it isn't possible, or practical,
then fallback to a Landlock specific API.

-- 
paul-moore.com