[RFC] LSM deprecation / removal policies

[Casey Schaufler]

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.

> On 2025/05/06 5:58, Paul Moore wrote:
>> On Sat, May 3, 2025 at 1:09 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>>> That's dangerously close to suggesting that the LSM hook list is an external API.
>>> It would be really inconvenient if hooks could never change or go away.
>> Unfortunately, this is one of the challenges that out-of-tree LSMs are
>> going to face.  As Casey already mentioned, LSM hooks are not part of
>> the kernel's userspace API and thus not part of the "don't break
>> userspace" edict.
> Due to the difficulty of making non-BPF LSMs in-tree due to the "patent examination"
> ( https://lkml.kernel.org/r/5b09909b-fe43-4a9c-b9a7-2e1122b2cdb6@I-love.SAKURA.ne.jp ),
> I don't think it is fair to assert
>
>   LSM hooks are not part of the kernel's userspace API and thus not part of
>   the "don't break userspace" edict
>
> without granting all (I mean, both in-tree and out-of-tree, and both BPF-based
> and non BPF-based) LSM users the right to join the discussion and comment on
> LSM hook changes.

I don't think that anyone with a legitimate concern regarding a change to
the LSM interface is going to be precluded from joining in the discussion.
That doesn't mean that someone protesting that the change breaks out-of-tree
code is going to prevent the change from being made, but if there is a real
issue that affects all users of the interface we'll want to hear about it.
The problem remains: if we can't see why there's an issue we can't respond
to the issue.