Re: [PATCH bpf-next v3 04/15] lsm: Add the bpf_lsm_policy_release kfunc and policy object destructor

["Günther Noack" <gnoack3000@gmail.com>]

On Tue, Sep 15, 2026 at 11:25:13AM +0200, Mickaël Salaün wrote:
> On Sat, Sep 12, 2026 at 12:33:13PM -0700, Alexei Starovoitov wrote:
> > On Fri Sep 11, 2026 at 10:26 PM PDT, Justin Suess wrote:
> 
> [...]
> 
> > landlock was designed for unprivileged users. bpf needs CAP_BPF.
> 
> Yep, and this series would kind of bridge these two worlds. ;)
> 
> > There is a fundamental disconnect. If you can tolerate CAP_BPF then
> > just use bpf-lsm and implement whatever policy you need there.
> > If bpf-lsm is missing a feature we can fix that.
> 
> The question is not if BPF LSM can or cannot do what Landlock does.
> Landlock provides a way for userspace to sandbox processes, and that
> comes with a well-defined semantic, logs, and an user space ABI, which
> are specific and dedicated to Landlock.  Some user space depend on that.
> 
> The goal of this patch series is to improve BPF LSM to enable it to
> (also) enforce a Landlock security policy defined by user space thanks
> to the Landlock syscalls.  The security policy still has the properties
> that makes it possible to safely compose different ones (e.g.
> monotonicity/stacking enforcement, inheritance, separation of duty, no
> cover channel, safe privilege reduction without confused deputy issues).
> 
> A process can currently define such security policy, get a file
> descriptor referring to it, and pass this FD to another process that
> would enforce it.  This helps design secure architectures by splitting
> ownership, trust, and privileges (e.g. CAP_BPF).  Being able to use BPF
> programs instead of user space programs to enforce (e.g. an already
> defined) security policy would make this enforcement more powerful
> thanks to the context BPF have access to.  Of course, BPF LSM can (and
> should) also enforce other kind of complementary restrictions.

I'd like to voice my support for this here and maybe try to make more
concrete the "bridging of the two worlds".

For normal Landlock use, CAP_BPF can *not* be assumed because Landlock
is designed to be used by unprivileged processes.  (See
https://landlock.io/integrations/ for an incomplete list of programs
already using it.)  It works similar to the unprivileged use of
seccomp-bpf: The unprivileged process both defines and enforces the
Landlock policy, by invoking unprivileged syscalls.

So a full rewrite of Landlock in eBPF seems infeasible (and TBH, it
would be quite a drastic deviation from the original scope of this
patch set).

However: It *is* true that a program that would use Justin's patch set
*would* need CAP_BPF to use it, and therefore that program *could*
also implement custom logic with the BPF-LSM.

But then again, since Landlock anyway already ships with well-reviewed
policy logic for the normal unprivileged use-case, I don't understand
why it should not be allowed for CAP_BPF programs to lean on that?  It
may be technically feasible to reimplement similar policies in eBPF,
but it might also avoid a lot of complication and potential bugs if
people could lean on a maintained solution like Landlock for the
aspects where it fits the purpose?

–Günther