Hardcoded security module suggestion - stop the stacking insanity

[Casey Schaufler]

On 4/9/2024 10:22 AM, 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.
>
> 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".

I'm perfectly good with changing LSMs from using indirect calls to
using some other technology. I'm fine with doing it an compile time,
if that's what's required. I'm OK (can't speak for anyone else) if
we have to break the ability to specify which LSMs are active on the
boot line.

> 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

I get it. Indirect branches are bad. Should never have been allowed
in the first place. When I did the implementation it seemed like a
good idea at the time. Looks like I was wrong.

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

I can sure see where that conclusion comes from. One of my goals with
LSM stacking is to encourage smaller, more directed security facilities.
I am not the believer in fine grained access control that many others
are.

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

Without the flexibility we're stuck with SELinux and its policy based
"security" model forever.

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

Got it. Abandon indirect calls. Reduce complexity.

The question is what would be acceptable? I've been proposing LSM
infrastructure changes for a painfully long time. I'd be
de-f***ing-lighted to hear what would be better than what we have now.
While I can't change the brain dead behavior of 21st century hardware
I am perfectly willing to re-write the entire $%^&*( LSM layer if it
can be done in a way that makes you happy.

>
>                   Linus
>