[RFC] LSM deprecation / removal policies
Song Liu
song at kernel.org
Tue May 6 00:21:29 UTC 2025
On Mon, May 5, 2025 at 4:10 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On Mon, May 5, 2025 at 5:54 PM Song Liu <song at kernel.org> 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.
>
> Sure, however, like you said, we aren't going to keep a LSM hook
> simply because it is used by a selftest.
Agreed 100%. If it makes sense to remove a LSM hook, we will adjust the
selftest accordingly.
Song
More information about the Linux-security-module-archive
mailing list