Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs

On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <[email protected]> wrote:
> > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <[email protected]> wrote:
> > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <[email protected]> wrote:
> > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > from accessing unstable internal Landlock fields.
> > > > >
> > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > function as examples.
> >
> > This patch series is not about the LSM framework, only about Landlock
> > and its specific model and use case.  Landlock using some of the LSM API
> > is not relevant here.
> 
> Based on a quick look the patchset enables BPF programs to call
> directly into Landlock.  For the same reason we discourage other parts
> of the kernel to call directly into individual LSMs, we want to
> discourage BPF programs from calling directly into individual LSMs.

We're OK for a dedicated kfunc to call directly into Landlock (with a
tailored interface).  Landlock is designed around its syscall interfaces
(well documented, tailored, tested), and this would be a new user of
almost the same UAPI.