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

[Justin Suess <utilityemal77@gmail.com>]

On Sun, Sep 13, 2026 at 07:31:44PM -0700, Alexei Starovoitov wrote:
> On Sun, Sep 13, 2026 at 5:20 PM Justin Suess <utilityemal77@gmail.com> wrote:
> >
> > Sure, in some perfect world in the future where every verifier
> > challenge is solved and BPF has feature parity with in-tree c on
> > a 1:1 basis, you could implement something like SELinux, or Landlock
> > in pure eBPF.
> 
> Try.. give it a shot? What is missing in the verifier?
>
Howdy Alexei,

I'll stick to Landlock as the concrete case, as it's what I'm most familiar with.

From security/landlock/fs.c: hook_sb_delete() holds the superblock's
s_inode_list_lock, takes a nested lock of the inode's i_lock inside it, takes the RCU
read lock inside that to dereference the per-inode Landlock object, and
then the object's own lock, which is four levels of lock nesting, and even with
all of that it still has to handle a race by re-checking
inode_state_read() for specific flags to maintain VFS invariants.  BPF
cannot take any of these kernel locks, and the current BPF locking model
deliberately excludes any nesting (bpf_spin_lock) or resolves contention by
bailing out (trylock style); the opposite of what maintaining VFS invariants
requires.  To do effective inode-based access control without TOCTOU or
bailing out of a long path walk, you'd need to solve nested locking with colored
locks: inode spinlocks, superblock locks, unix_state_lock, etc, and
solve nested locking along the way.

You'd also need to convince the verifier that an upward VFS walk
(dget_parent) is bounded, and find a way to cross mount boundaries;
getting from a vfsmount to its struct mount is container_of(). (Pointer
is arithmetic rejected even on trusted pointers).  Pointers walked
via d_parent become untrusted, so they can't be passed to any kfunc
(bpf_path_d_path(), bpf_inode_storage_get()): inode local storage,
which is otherwise an idiomatic inode security blob replacement, is only
usable for the object at hand, but not its ancestors required for VFS
walk.

Making it string/pathname based instead doesn't help either: any string-based method
fails because the same file can be linked from multiple places, the same
path string means different things in different mount namespaces, and
strings aren't TOCTOU safe (the path can change during the walk).  And you can't
currently take references or locks on inodes, dentries or mounts from
BPF, so any hierarchy walk is a lockless, unreferenced snapshot racing
against rename, whereas Landlock's walk holds path_get()/dget_parent() 
holds the references at every step.

You'd also need credential-attached storage. BPF task storage has a
different lifecycle, and is no substitute. It does not define how policy
is shared by threads using the same credentials, copied or replaced
during credential transitions, propogated through file->f_cred,
or synchronized across a thread group. Recreating those semantics in
BPF would require explicit BPF APIs for credential storage to be
consistent.

> > Why force every eBPF program that needs to make security
> > decisions to reeinvent the wheel?
> 
> What specific reinvention are you talking about?
>
Path based access control, done to the same correctness 
level as in Landlock, (TOCTOU free).
> > BPF already calls into LSM through security hooks. This is no
> > different than bpf_map_create hooks.
> 
> what? It doesn't. bpf progs avoid lsm hooks as a plague.
> Not a single kfuncs calls into lsm directly.
> It may call into security_*() by accident because
> it calls some kernel mechanisms.
>

I was referring to the security_bpf_map_create()
call in kernel/bpf/syscall.c, where BPF calls into LSM via an LSM hook
just to show that kernel/bpf already calls security hooks directly
(and now that I look, there are other security_bpf_*() calls in
kernel/bpf/ too).  Those hooks exist so LSM can mediate what BPF is
allowed to do.

(These in this patch hooks are contrary; they are giving BPF control over
LSM policy. And, indeed, no hook is called from kfuncs, as you stated).

The proposal is intended to add a narrow generic bridge, not to expose
Landlock-specific kfuncs or make BPF depend on Landlock internals:


  /* setup (BPF_PROG_TYPE_SYSCALL context) */
  obj = bpf_lsm_policy_from_fd(fd, 0);
  old = bpf_kptr_xchg(&map_val->policy, obj);
  
  /* enforcement (sleepable BPF_PROG_TYPE_LSM on a bprm hook) */
  bpf_rcu_read_lock();
  obj = bpf_lsm_policy_acquire(map_val->policy);
  bpf_rcu_read_unlock();
  if (obj) {
         bpf_lsm_policy_apply_bprm(obj, bprm, 0);
         bpf_lsm_policy_release(obj);
  }

BPF never sees a Landlock kptr or any Landlock-specific type.  It holds
an opaque policy reference and invokes a generic operation. The LSM
can evolve its internal representation and its hook-specific
implementation without exporting breakage into the BPF ABI: the signature
of the data the LSM sees can change independently of the kfunc (that's
what the body-less hooks in patches 1-2 are for), avoiding breakage and
easing refactoring.

> > Nothing about the way BPF works changes with this patchset.
> > There's no verifier internal changes.
> 
> If the verifier is in the way of what you want to accomplish
> then please improve it.

There are also verifier improvements I'd like to make, (I can also work
on these if you desire prerequisites or seperate fixes).

For instance, my silly bpf_lsm_policy_apply_bprm allowlist exists
because there's no way to distinguish a linux_binprm seen from a
tracepoint from one seen in an LSM hook (both are KF_TRUSTED) and
it matters because there are tracepoints where it's no longer safe to
modify the linux_binprm.

I'd rather have the verifier do that legwork through its type system
than through BTF_ID sets, and I think you feel the same way.

....

The goal here is to keep LSM firmly *out of the way* of BPF business
and let each subsystem focus on its core technology. It's my belief
BPF and LSM  subsystems can benefit from something like this given a chance,
with a well-defined structured interface / guardrails.

All in good faith, 
Justin