[RFC] LSM deprecation / removal policies

[Paul Moore]

On Wed, May 7, 2025 at 12:24 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> On 5/7/2025 4:06 AM, Tetsuo Handa wrote:
> > On 2025/05/06 6:53, Song Liu wrote:
> >> On Sat, May 3, 2025 at 4:47 AM Tetsuo Handa
> >> <penguin-kernel at i-love.sakura.ne.jp> wrote:
> >>> On 2025/05/03 5:01, Paul Moore wrote:
> >>>> ## Removing LSM Hooks
> >>>>
> >>>> If a LSM hook is no longer used by any in-kernel LSMs, there is no ongoing work
> >>>> in progress involving the hook, and no expectation of future work that will use
> >>>> the hook, the LSM community may consider removal of the LSM hook.  The decision
> >>>> to ultimately remove the LSM hook should balance ongoing maintenance and
> >>>> performance concerns with the social challenges of reintroducing the hook if
> >>>> it is needed at a later date.
> >>> What about BPF-based LSM users? Since BPF-based LSMs cannot be in-kernel LSMs,
> >>> it will be difficult for users of BPF-based LSMs to respond (that someone wants
> >>> some to-be-removed LSM hook) when removal of an LSM hook is proposed.
> >> If a LSM hook is important for an out-of-tree BPF LSM solution, the owner can
> >> add a BPF selftest for this specific hook. This does not guarantee the hook will
> >> stay, but it can most likely detect unintentional removal of LSM hooks.
> >>
> > The problem is that the owner out-of-tree BPF LSM solution cannot join the
> > discussion about LSM hooks being modified/removed. That is, out-of-tree BPF
> > LSMs will be forced to stay as unstable as out-of-tree non-BPF LSMs.
>
> The same issue applies to out-of-tree filesystems and device drivers.
> There's no problem that is new or unique to the LSM interface here.

Exactly.  Out-of-tree kernel code is out-of-tree code.  Tetsuo, we've
already had this discussion many times, and my opinion on this has not
changed since we last discussed this topic.

-- 
paul-moore.com