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

["Mickaël Salaün" <mic@digikod.net>]

Hi,

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.