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

["Dr. Greg" <greg@enjellic.com>]

On Mon, Sep 14, 2026 at 09:13:29PM -0400, Justin Suess wrote:

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

Excellent summary.

Alexei, for those of us contemplating potentially large BPF-LSM
projects, does this imply that eBPF may never be ready for other than
small boutique based security implementations?

Interested in your thoughts.

> (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:

Based on Micka's mail that we responded to, this seems contrary to the
intent of what you are trying to implement.

We can see where you are not making BPF depend on LandLock internals.

However, from his description, the intent is to have a process compose
a LandLock policy and then hand enforcement off to an eBPF program,
which on the surface would seem to suggest that the intent is to allow
eBPF programs to enforce LandLock specific functionality and controls.

Perhaps we still misunderstand.

> All in good faith, 
> Justin

The same.

Greg

My opinions and those of my Golden Retriever Hezzie only.