Re: Hardcoded security module suggestion - stop the stacking insanity

[Kees Cook <keescook@chromium.org>]

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