Re: [PATCH] lsm: make SECURITY_PATH always enabled

[Paul Moore <paul@paul-moore.com>]

On Apr 22, 2025 Song Liu <song@kernel.org> wrote:
> 
> Only TOMOYO needed CONFIG_SECURITY_PATH when it was introduced. But now,
> AppArmor, EVM, IMA and LandLock also need it. And kernels are likely built
> with at least one of these enabled if CONFIG_SECURITY is enabled. Let's
> simplify the dependency.
> 
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Signed-off-by: Song Liu <song@kernel.org>
> ---
> This was initially proposed in [1], but got Nacked by Paul.

I chose not to merge the patch with the following comment:

 "If a Kconfig option is only needed by a subset of LSMs, which is the
  case for CONFIG_SECURITY_PATH, it should remain a build-time option."

... and that reasoning still sounds reasonable to me today.

> ... but it is really up to the LSMs to decide how
> they use struct path.

LSMs are currently free to select CONFIG_SECURITY_PATH as needed.  In
fact, if you look any modern Linux tree you'll see that TOMOYO, AppArmor,
Landlock, IMA, and EVM all select CONFIG_SECURITY_PATH based on their
individual Kconfig settings.

> The separation of CONFIG_SECURITY and CONFIG_SECURITY_PATH has actually
> caused confusion. In some of our early kernels, we enabled CONFIG_SECURITY
> but not CONFIG_SECURITY_PATH. Now, we have to add separate logic in user
> space to deal with missing CONFIG_SECURITY_PATH in these systems.

I'm sorry that you made some Kconfig choices on a production kernel that
you now regret, but that doesn't change things from an upstream
perspective.  The exception of course would be if there was a LSM that
*required* CONFIG_SECURITY_PATH but did not enable it or mark it as a
dependency in the LSM's Kconfig.  It doesn't sound like that is the case
here, but please let me know if that was the root cause so we can work
with the individual LSM to fix the associated Kconfig.

As you likely know, the LSM subsystem as a whole (framework and
individual LSMs) is often criticized over various performance impacts;
one of the easiest ways to limit the impact of the LSM on overall system
performance is to remove LSM hooks that are not needed.  Keeping the
CONFIG_SECURITY_PATH hooks as-is and allowing individual LSMs to opt-in
as needed is a reasonable balance between providing the necessary LSM
hook support and limiting performance impacts.

--
paul-moore.com