Re: Hardcoded security module suggestion - stop the stacking insanity

[Kees Cook <keescook@chromium.org>]

On Tue, Apr 09, 2024 at 10:22:42AM -0700, Linus Torvalds wrote:
> People, I know there's been LSM work on the whole "multiple layers of
> security modules" for over a decade, and it's been a design decision
> and a target, but I've complained before about the cost of the
> abstraction, and we just had *another* hardware security issue with
> speculated indirect branches go public.

There are 2 aspects to the LSM stacking: providing non-overlapping small
LSMs (e.g. lockdown, LoadPin, Yama, etc) with a "major" LSM (e.g. SELinux
or AppArmor). This has been needed going back a decade as core kernel
maintainers did not want to be bothered with all the needed knobs
touching core kernel internals. (This is not an unreasonable request:
userspace _does_ need to be able to apply policy at runtime, and this
goes well beyond standard MAC systems, e.g. LandLock.)

The second is providing proper container support for differing "major"
LSMs, which has been in use for many years now (e.g. running a RedHat
container using SELinux inside an Ubuntu host using AppArmor). This is
what is conceptually considered "nesting", but is nothing more than a
special case of the "non-overlapping" case above.

The general "LSM stacking" work, while it does add a certain kind of
complexity, has actually made the many pre-existing manual layering of
LSMs much more sane and simpler to reason about. Now the security hooks
are no longer a random sprinkling of calls tossed over the core kernel,
and are now all singularly well defined. This started years ago with
pulling the "capabilities" checking into a well-defined LSM, and continued
from there for things like Yama, and has now finally reached the last,
and perhaps most historically invasive, LSM: IMA/EVM, which is finally
now a well defined LSM too.

I don't think it's sane to demand that LSM stacking be removed. That's
just not the world we live in -- we have specific and large scale needs
for the infrastructure that is in place.

> So I say "suggestion" in the subject line, but  really think it needs
> to be more than that: this whole "nested LSM" stuff as a design goal
> just needs to be all rolled back, and the new design target is "one
> LSM, enabled statically at build time, without the need for indirect
> calls".

"One LSM" isn't the same as "no nesting". And "no nesting" is both not
acceptable given the users of it, and doesn't eliminate LSM "stacking".
But "without indirect calls" is totally doable.

> And yes, I'm aware of the random hacks for turning the indirect branch
> into a series of static direct branches by
> 
>    https://lore.kernel.org/bpf/20240207124918.3498756-1-kpsingh@kernel.org/#t

I don't think describing static calls as "random hacks" is very fair;
it's used pretty extensively in the kernel. Regardless, this series has
needed to land for well over a year now, even if just for the performance
benefits.

-- 
Kees Cook