Hardcoded security module suggestion - stop the stacking insanity

Hardcoded security module suggestion - stop the stacking insanity

[Linus Torvalds]

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

Re: Hardcoded security module suggestion - stop the stacking insanity

[Kees Cook]

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

Re: Hardcoded security module suggestion - stop the stacking insanity

[Linus Torvalds]

On Tue, 9 Apr 2024 at 11:02, Kees Cook <keescook@chromium.org> wrote:
>
> 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.

I think we really need to push back on this all.

The whole stacking is new. There can't be too many users. And it damn
well can be limited.

Right now that sttaic stacking code is written to allow 11 levels.

Why? Just because you people cannot agree.

Stop it.

> I don't think describing static calls as "random hacks" is very fair;

Static calls aren't random hacks.

But the "up to eleven levens of nesting" and "reorider arbitrarily" IS.

This needs to be *fixed*.

Seriously, what part of "this is now an attack vector" did people not get?

            Linus

Re: Hardcoded security module suggestion - stop the stacking insanity

[Kees Cook]

On Tue, Apr 09, 2024 at 11:24:44AM -0700, Linus Torvalds wrote:
> On Tue, 9 Apr 2024 at 11:02, Kees Cook <keescook@chromium.org> wrote:
> >
> > 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.
> 
> I think we really need to push back on this all.

I'll wait for Paul to comment more, but I feel like there's a
misunderstanding about how LSM stacking works and we're talking past
each other.

> The whole stacking is new. There can't be too many users. And it damn
> well can be limited.

Stacking is old. A small handful of, IIRC, network hooks that only the
traditional "large MAC" LSMs uses weren't stackable. And it's been like
that for a long time.

> Right now that sttaic stacking code is written to allow 11 levels.

Just trying to be clear again: the LSMs compose, as they always have,
via hooks. There is nothing new here. The static calls patch needs a
fixed number for the array, which just comes from the LSM count.

> Why? Just because you people cannot agree.

"Agree"? On what? Each LSM has different purposes. Only a few are the
traditional "full MAC" systems. For example, on my Ubuntu 22.04 (now 2
years old), the default is:

CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor"

And note that "capabilities" isn't listed here because it's not removable.
Each of these subsystems do different things. This isn't "nesting",
they're just literally the list of subsystems to use.

> > I don't think describing static calls as "random hacks" is very fair;
> 
> Static calls aren't random hacks.
> 
> But the "up to eleven levens of nesting" and "reorider arbitrarily" IS.

Maybe the better language is "compose", not "stack" or "nest".

> Seriously, what part of "this is now an attack vector" did people not get?

Come on; the attack vector is broken CPUs. There are plenty of indirect
calls in the kernel, it just happens that for this case it was easiest
to get at the LSM's. Next time it could be networking -- close()ing a
socket runs a protocol-specific indirect release handler. It would be
just as silly to hard-code our available network protocols.

Networking did try to reduce the retpoline overhead with a single if/else
for the common case, but it's still making an indirect call if it needs
to. In LSM, we've explicitly been working to turn the LSM hooks into 100%
static calls since before this latest CPU errata was even found. :|

-- 
Kees Cook

Re: Hardcoded security module suggestion - stop the stacking insanity

[Dr. Greg]

On Tue, Apr 09, 2024 at 11:24:44AM -0700, Linus Torvalds wrote:

Good morning, I hope the week is winding down well for everyone.

> On Tue, 9 Apr 2024 at 11:02, Kees Cook <keescook@chromium.org> wrote:
> >
> > 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.
> 
> I think we really need to push back on this all.
> 
> The whole stacking is new. There can't be too many users. And it damn
> well can be limited.
> 
> Right now that sttaic stacking code is written to allow 11 levels.
> 
> Why? Just because you people cannot agree.
> 
> Stop it.

Kees' response is well taken.  There is about as much chance of
everyone agreeing on what type of security control to implement as
there is on the one file system or text editor that everyone should
use.

We are also rapidly racing into an environment where there are going
to be multiple and potentially industry specific mandated security
controls, particularly as Linux takes over the critical infrastructure
control market.

> > I don't think describing static calls as "random hacks" is very fair;
> 
> Static calls aren't random hacks.
> 
> But the "up to eleven levens of nesting" and "reorider arbitrarily" IS.
> 
> This needs to be *fixed*.
> 
> Seriously, what part of "this is now an attack vector" did people
> not get?

I don't believe there is any active disagreement with respect to the
need to eliminate an attack vector and the performance impacts of
indirect branching.

Doing so is going to raise a number of issues, many of which will
determine whether or not Linux will be in a position to support the
security development that will be required moving forward.

The one LSM that rules all paradigm is fine, but that LSM needs to be
able to support multiple and diverse security policies or models.  We
are in the situation we are in now because our security architecture
required a separate LSM for each type of security policy/model that
there was a desire to implement.

From a technical perspective, this leaves us in a situation where
multiple security architectures are simultaneously active, with users
left to reason as to what security behavior results from the union of
the respective controls.  Specific LSM ordering ends up being demanded
because LSM's either want to be first, before another, after another
or at the end and the issues go on and on.

Most fundamentally limiting, we are left in a situation where anyone
with a technical requirement, or interest, in using Linux as a
platform for security development needs to get an LSM accepted into
the mainline kernel.  A requirement that is problematic if not
completely unrealistic.

The static branch patches are going to codify this latter requirement.
If we don't have an effective technical solution, it will end up
impairing the future usability of Linux from a security perspective.

There needs to be an 'LSM' architecture that allows a security policy
to be implemented for a process hierarchy, just like we do for all
other resource namespaces.  Platform owners are then free to select
whether they want to implement multiple orthogonal security controls
or lock the platform into a single control of their choosing.

This seems consistent with the history of Linux and free software
being about choice and the ability to use a system as one chooses to.

This isn't to suggest that infrastructural controls, such as
capabilities, would not be simultaneously active with more
comprehensive model or policy based controls.

LSM's based on loadable modules were rejected because it wasn't
possible to do that safely, ie. race free.  This issue goes away if a
model/policy is available for a process hierarchy to subscribe to,
before the use of the control method is engaged.  That being said, a
model/policy configurable LSM doesn't need to require loadable modules
but we use that as a metaphor that everyone understands.

There may be an inclination to shout BPF but the following should be
taken into consideration:

https://lore.kernel.org/linux-security-module/CAHC9VhRruSLET+aOhCt7WKucWNBE_qLCYV3won+p10XOjLLiHQ@mail.gmail.com/T/#m4cbae6c1d8371e7994a57700dcbcab03bf9d1146

BPF is an extremely useful adjunctive technology.  However, achieving
something of the status of a major security control engine will end up
necessitating the development and introduction of a collection of
kfuncs, a barrier not unlike the introduction of a new LSM.

>             Linus

FWIW, we didn't come by these impressions from the cheap seats and we
will leave our motivations for composing this note at that.

Have a good remainder of the week.

As always,
Dr. Greg

   The Quixote Project - Flailing at the Travails of Cybersecurity
		  https://github.com/Quixote-Project

Re: 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
>

Re: Hardcoded security module suggestion - stop the stacking insanity

[Paul Moore]

On Tue, Apr 9, 2024 at 7:34 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> 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.

Relax Casey, no one is rewriting the entire LSM layer. Perhaps more
accurately, I'm not going to merge a single patchset that throws
everything out and substitutes a single-LSM approach to satisfy a spur
of the moment comment triggered by the latest hardware flaw.

We'll sort out the static call conversion first and go from there.

-- 
paul-moore.com

Re: Hardcoded security module suggestion - stop the stacking insanity

[Paul Moore]

On Tue, Apr 9, 2024 at 1:23 PM Linus Torvalds
<torvalds@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