Hardcoded security module suggestion - stop the stacking insanity

[Paul Moore]

On Tue, Apr 9, 2024 at 1:23 PM Linus Torvalds
<torvalds at linux-foundation.org> 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".
>
> 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".

I guess you just couldn't help but add the above sentence.  Maybe it's
your narrow definition of security, maybe it's just an old habit that
comes back in times of stress, maybe it's something else ... I don't
know, but I do know that telling the LSM folks that we "don't actually
care about real security" is both objectively wrong and a slap in the
face.  The insult is made significantly worse due to your position;
other developers, maintainers, etc. see comments like you made above
and believe it's okay to direspect the LSM infrastructure and the devs
who support and look after it.

Even if you stand behind what you wrote above and it wasn't just
yet-another-hardware-flaw-rage-post, I find it hard to believe you
didn't understand your comments would be taken negatively by the LSM
devs, the same devs you are asking (demanding? it's hard to say at
this point) to upend some core design decisions.  I'm far from a
master of persuasion, but I do know that insulting the very people you
need to help you fix things is generally a poor idea.

I see your suggestion in this email, I'm sure we all do, and we'll act
on it.  It will likely be a while before the discussions turn into
merged code or design changes, but we'll move forward, we always do.
In turn, I'd like to make my own suggestion: do better Linus.
Disagree with the code, design ideas, project goals, etc., but don't
insult the people who have helped make Linux what it is today.

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

Ignoring my objections to the very premise of the question ...

As Kees already pointed out, we're at a point where we really don't
have the ability to rollback LSM stacking without negatively impacting
the user experience.  While I'm sure there are some public distros
that don't enable the LSM, last I looked all of the major  public
distros did, and practically all of those have multiple LSMs enabled
... and have for years now.

Even if we did decide to eliminate stacking, I'm not sure it would be
a net positive change.  Many here may have forgotten the ugliness that
we had in the early days where individual LSMs had to directly call
into the capability LSM if they wanted to preserve that behavior.
Yama, the first "minor" LSM (ignoring capabilities) was brought into
existence because other subsystem maintainers couldn't agree to
support the functionality; would those same maintainers be willing to
incorporate Yama directly now?  We also have the recent example of IMA
and EVM, where promoting them to proper LSMs enabled us to simplify
the LSM/IMA/EVM call sites in the VFS and LSM layers which made
several maintainers happy (although it was a source of significant
stress for the IMA/EVM devs, I appreciate their help and understanding
in that effort).  Do we really want to add that complexity back into
other parts of the kernel, one hook at a time?  Would that really be
an improvement?

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

To be very clear, the core vulnerability that triggered this thread is
rooted in a hardware flaw.  I'm not going to argue against mitigating
the vulnerability by reducing the attack vectors, but let's reserve
the rage and cute quotes for the core problem.

I'm going to bump the static call patchset up the review queue and
we'll start there; getting that in an agreeable state and merged
should at least resolve the indirect call concerns.  The rest will
need more discussion, preferably after things have cooled down and we
call all look at things with a more objective lens.

-- 
paul-moore.com