[RFC] LSM deprecation / removal policies
Casey Schaufler
casey at schaufler-ca.com
Sat May 3 17:09:03 UTC 2025
On 5/3/2025 4:07 AM, Tetsuo Handa 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.
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. It would
be especially bad if, for example, vfs changes made a hook obsolete. There is no
way that Al Viro is going to eschew a significant performance improvement to
maintain the interface or existence of an LSM hook.
>> ## Removing LSMs
>>
>> If a LSM has not been actively maintained for a period of time such that it is
>> becoming a maintenance burden for other developers, or there are serious
>> concerns about the LSM's ability to deliver on its stated purpose, the LSM
>> community may consider deprecating and ultimately removing the LSM from the
>> Linux kernel. However, before considering deprecation, the LSM community
>> should make every reasonable effort to find a suitable maintainer for the LSM
>> while also surveying the major Linux distributions to better understand the
>> impact a deprecation would have on the downstream distro/user experience. If
>> deprecation remains the only viable option, the following process should be
>> used as a starting point for deprecating the LSM:
> What about users using the major Linux distributions whose kernel's major version
> won't change frequently (e.g. some enterprise distro has 10 years of lifetime, and
> would require 3 or 4 years when updating such distro's major version) ? Such users
> likely fail to know that deprecation process is in progress, and likely suddenly
> be notified of removal of LSMs one day. I agree that the upstream kernel may need
> to remove no longer maintained LSMs, but it will be hard to make an assumption that
> any reasonable user has already seen the deprecation messages.
As you've pointed out many times in the past, users of major distributions are
unlikely to mess with the LSM configuration. If Redhat came to their senses and
replaced SELinux with a combination of Smack and TOMOYO very few would be the
wiser. :)
More information about the Linux-security-module-archive
mailing list