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

On Thu, Jul 30, 2026 at 10:21=E2=80=AFPM Justin Suess <utilityemal77@gmail.=
com> wrote:
>
> Howdy,
>
> This series lets BPF programs apply an existing, userspace-created
> Landlock ruleset to a program during exec.  The goal is unchanged from
> the RFC [1]: BPF does not create, inspect, or mutate Landlock policy,
> it only decides whether a ruleset that was already created and
> validated through Landlock's existing userspace API should be applied,
> based on runtime exec context.
>
> Motivation
> ---
> Deploying Landlock today requires the sandboxed program's
> cooperation.  A process can only restrict itself, so applying a
> policy system-wide means wrapping every launch path with a helper
> that calls landlock_restrict_self(2) before exec, and anything
> spawned outside those wrappers runs unconfined.  Supervising exec
> from userspace instead (ptrace, seccomp user notifications) is racy
> and slow.  Meanwhile, the tools that do enforce system-wide policy
> with BPF LSM programs today (container security agents such as
> KubeArmor and Tetragon) end up reimplementing path-based access
> control in BPF, fraught with horrors of path reconstruction, bind
> mounts, rename races, and worse, which is exactly the problem Landlock
> already solves in the kernel, with maintained and versioned semantics.
>
> This series composes BPF and Landlock along their natural grain.  The
> intended deployment: a supervisor creates one ruleset per policy
> class through the existing syscalls, a syscall BPF program parks
> them in map kptr fields, and an LSM BPF program picks which (if
> any) to apply to an execution based on its runtime context.  The
> policy semantics stay Landlock's; BPF contributes only the
> programmable decision of when and to whom.  Deciding inside the
> exec path closes the race a userspace supervisor cannot: the
> policy is in place before the first instruction of the new program
> runs.

Discretionary models are fun, and useful in certain situations, but
they do have their limitations ;)  To be fair, mandatory models have
their limitations too :)

I've only just barely skimmed some of the patches in this patchset,
and I didn't have a chance to fully read your reply in the previous
revision yet, so I wanted to get you a quick response here ... as
incomplete as it may be.

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.

I need to look closer at both the LSM hooks and the BPF kfuncs before
I can really definitively comment on them.  It looks like there has
been some progress towards an LSM agnostic interface, but I'm
concerned more work might be needed.  However, as I said earlier, a
closer examination is needed and perhaps that will reveal something
different.

It's also worth mentioning that this functionality looks an awful lot
like a call to lsm_set_self_attr(LSM_ATTR_EXEC,
<lsm_ctx:LSM_ID_LANDLOCK>, size, 0) with a lsm_ctx::ctx set to a
policy fd.  Once again, perhaps a closer inspection will reveal that
it is nothing like that, but it kept popping into my head while
reading things so I wanted to mention it, especially as it a lot of
the framework infrastructure already exists.

--=20
paul-moore.com