[RFC] LSM deprecation / removal policies

[Paul Moore]

On Sat, May 3, 2025 at 1:09 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> 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.

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.

> >> ## 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.

For a variety of reasons such as extended support lifetimes and
out-of-tree customizations, it is impossible for upstream to support
all Enterprise Linux users, this is why a large part of the Enterprise
Linux distro story is support; Enterprise Linux users get their
support from the company that provides the distro, not upstream.

With all that said, you will note that the guidance documented above
explains that the upstream 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 Redhat came to their senses and
> replaced SELinux with a combination of Smack and TOMOYO very few would be the
> wiser. :)

I'm sure they would enjoy seeing such a feature request bubble up
through their Bugzilla ;)

-- 
paul-moore.com