Hardcoded security module suggestion - stop the stacking insanity
Linus Torvalds
torvalds at linux-foundation.org
Tue Apr 9 17:22:42 UTC 2024
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.
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".
Because we're now in the situation where the security hooks are
actually a source of not just horrible performance issues, but also
actual insecurity. The first indirect branch in the kernel is now
often the security layer, and the latest
One current PoC literally uses security_task_prctl() as the attack vector.
Yes, I realize that the "security" in the LSM name is a bad joke, and
that to a first level approximation the LSM people don't actually care
about real security, and that the goal is just "policy".
But dammit, I think we need to put our foot down on this. The
complexity simply isn't worth it, and the flexibility is of
questionable actual worth.
So here's a challenge to the LSM people: work on walking back all the
silly nested security layers.
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
but honestly, this series needs to be turned to 11.
Or rather, it needs to be turned *down* from the current maximum of 11
nested calls to be something sane. This whole "security layer allows
any policy at all" has been a fundamental design mistake. It
absolutely needs to stop, and this "you can nest arbitrarily" needs to
be walked back.
The whole "add cost and insecurity in order to give people random
policies" must go. When the LSM *becomes* the attack vector, we need
to just fix things.
Linus
More information about the Linux-security-module-archive
mailing list