[RFC] LSM deprecation / removal policies

[Tetsuo Handa]

On 2025/05/08 5:14, Paul Moore wrote:
> 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:
>>> 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.
> 

Out-of-tree filesystems and out-of-tree device drivers can be built as
loadable kernel modules whereas out-of-tree LSM modules cannot be legally
built as loadable kernel modules. And replacing the whole kernel in order to
enable out-of-tree LSM modules (or in-tree but not-builtin LSM modules) is
a big barrier.

Also, how many LSM modules have been accepted as in-tree after you started using
LSM ID as an identifier? I don't know how many device drivers have been accepted
as in-tree, but generally getting LSM modules in-tree is much difficult than
getting device drivers in-tree. Yet another big barrier!

This problem is new and unique to LSM.