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

[Mickaël Salaün]

On Wed, Sep 16, 2026 at 12:02:41PM -0500, Dr. Greg wrote:
> 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'... ;-)

I'm pragmatic and there are different use cases, different constraints,
and different trust models...  Landlock has some good properties which
makes it fit for being used by unprivileged/untrusted processes, and who
can do more can do less.

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

Please keep this in mind:
> > 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.

That's a different problem/challenge, but BPF is gradually being
improved, and I'm sure your contributions would be welcome.

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

That's kind of the opposite: systemd, as a privileged process, is in
charge of loading BPF programs, but this is not a good example here.
That would make more sense with e.g., a dedicated process that manages a
set of security policies (which might be owned by different teams), pass
these (Landlock) policies to the a privileged process that enrich them
with context, and load the related BPF programs to the kernel.  That's
only one simple example, but it should give a good idea of what is
possible.

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

Yes, that's a possibility, but a simpler approach would be to just map a
runtime context to a set of security policies (e.g. sandbox all
instances of /usr/bin/foo with a custom profile).

> 
> We will be interested in your reflections.