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

[Dr. Greg]

On Tue, Sep 15, 2026 at 11:25:13AM +0200, Micka??l Sala??n wrote:

> Hi,

Hezzie says hi too.

> 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. ;)

See my comments to Justin about this 'Mixing of the Blood'... ;-)

> > 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.

This may be the answer to the question that I was asking Justin, lets
see if we can unpack it a bit for those of us that are dense.

Big picture, as Justin so elegantly pointed out, there are a bunch of
things that eBPF cannot do now, and may never be able to do in the
future, particularily when it comes to 'raceless free' path based
security controls, ie. TOCTOU avoidance.

So, the objective is to have a program, systemd for example, compose a
set of different security policies, that it then hands out to various
process heirarchies, which then uses eBPF to call LandLock kernel
internals to do the heavy security lifting with kernel level
privileges and capabilities, particularily when it comes to path based
controls.

Is that close?

If so, the question remains, why take on this amount of drama?

Something like systemd does at least 10,000 other things, composing
and handing out multiple variants of file descriptor based process
hierarchy security policies would seem like chump change to it.

I'm assuming the answer is that the eBPF programs involved are going
to be implementing other, perhaps proprietary, security controls that
extend beyond the path based controls that eBPF can't do.

We will be interested in your reflections.

Greg

My opinions and those of my Golden Retriever Hezzie only.