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