From @torvalds on #LKML:

Hardcoded security module suggestion - stop the stacking insanity

https://lore.kernel.org/all/CAHk-%3Dwh%2B_xXpnHfUv%3DFwGWcce4XwqwKvtq7LcxK6WKmbf4eGGA@mail.gmail.com/

"'[…]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[…]"'

#Linux #kernel #LinuxKernel

@kernellogger @torvalds TOMOYO please

@kernellogger @torvalds Linus is right as usual

@oleksandr @kernellogger @torvalds

I think the more realistic starting point is to drop the nesting of major LSMs.

Have a simpler standard baseline security check (capability, bpf?) and then one build-time selectable major security module (SELinux, TOMOYO, YAMA, AppArmor, Smack, etc).

Then with time, a reduction of them will be the next step.

I do agree stacking more major security models on top of each other sounds fairly lunatic as a starting point. Nice from a user flexibility sales presentation. But that's about it too.

@kernellogger I was today years old, that's 20 in Linux years, to find out that besides AppArmor on all my Debian servers and SELinux on my Fedora workstation there's a heap of other LSMs that basically do the same, could be replaced by each other, but not quite.

@a_lex_ander

Not my area of expertise and I might totally mistaken/misremember here, but I think that stuff started in Linux 3.4 with Yama; and IIRC SELinux already had something similar (but not quite) already.

Maybe the world would be a better place if we would not have down that path, not sure. And maybe we should have decided on one security system from the start and make that fit everyone.

But I see the need to run a SELinux container on a AppArmor system and vice versa.

@kernellogger @torvalds Yama at least could just as well be config flag-enabled feature. It gains nothing for being an LSM but is useful security feature for most. Not really going to solve any of this but it is always good to start with the low-hanging fruit :-) Even if nested LSM's was beloved by everyone it still would not make sense as an LSM, and never has. Yama really should have been "CONFIG_PTRACE_RESTRICT_SCOPE" or similar and just a flagged feature with no connection to LSM's.

@kernellogger @torvalds Yama actually demonstrated the general problem in any possible framework: they can make blind on considering what the feature actually is and even "right feature" might go to a "wrong socket".

@kernellogger @torvalds

I’ve understood by reading LKML and LWN that the problem that nested LSM’s is trying can be described as follows:

1. Host is using LSM A.
2. Container is using LSM B.

Given that the most of the popular LSM’s are made for the sake of SELinux being too tedious to configure I’ve sometimes wondered why they could not just convert their policy to SELinux policy, and not be kernel features in the first place 🤷

That said, LSM’s are not my area really, and could easily overlook some aspects that might make them useful as kernel features.

@jarkko @torvalds

I often wondered if SELinux would have become way easier to configure and manage quickly long ago, if we early on had deemed it as the the one and only to rule them all (aka the "highlander")

@torvalds @kernellogger @jarkko if tooling like ls could be allowed to break their defaults to let me see why tftpd can’t see the file I just copied from my home to /srv/ftp then sure.

(100% agree though on one to rule them all. So fed up with the current state of things in this domain)

@troglobit @torvalds @kernellogger IMHO, the first thing that should be done would be to detach all the code out of LSM framework that is not an optional security module. That would bring some clarity on its purpose because then it would be more logically constrained entity.

Even if that causes a few additional calls around the hooks call site, it removes abstraction shenanigans and other unnecessary boilerplate code, and thus makes reading and debugging kernel code overall more pleasing experience.

E.g. documentation [1] states that "the Linux capabilities modules will always be included" but really does not gives existential reason for abstracting it that way. Maybe there are legit reasons for doing that but they are undocumented and I get a feeling that i'm in a spaceship with a bunch of architecture astronauts :-) [2]

[1] https://www.kernel.org/doc/html/latest/admin-guide/LSM/index.html
[2] https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/

@troglobit @kernellogger @torvalds I mean if you consider either POSIX capabilities and Yama both of them are only part of the "stacking problem" (two containers with different LSMs) only for the reason that they are implemented as LSM. Scaling down a problem to make it more manageable is usually the first step to more sane and healthy situation, right? :-)

@kernellogger @torvalds @troglobit Have been thinking about this and I’m aligning myself based on constraints that do exist.

Multiple LSMs do exist and since the major LSM’s are also used commercially there must be good reasons to pick one rather than another. Also there is probably bunch of real-world applications where container does not share the same LSM as the host.

The key problem in my opinion with stacking is that LSM is not well-defined entity enough. In order to being one it should be defined preferably in the kernel documentation what is NOT an LSM. If that had a great definition then I would support it.

It is not just about making that kind of constrain to the documentation but also refactoring some features out of the LSM cage. E.g. stacking Yama or POSIX capabilities does not have any meaning in that would make any sense to me. They really should be just plain kernel features.

If stacking involved only “actual” LSM’s then it could be actually useful feature. E.g. I could imagine applications that benefit the user base and does not turn out to be a freaking mess.

If i recall correctly there was yet another LSM in the queue. I’d consider blocking any new LSM’s up until this whole mess has been properly sorted. I still am puzzled about POSIX capabilities “LSM”, i.e. how it ended up to upstream because documentation does not provide any answer on its practical usefulness. On the contrary it gives good arguments of not keeping it inside LSM given that they are always on :-)

@jarkko as en end-user I frankly do not care who comes out on top. This is one of the features of Linux we need to be standardized and not have >1 flavor of. It's completely unusable and incomprehensible from userspace as it is right now. (Sorry for spamming) @kernellogger @torvalds

@troglobit @kernellogger @torvalds Not totally disagreeing with that, I mean never used any of these LSM's in my own machines :-) Still e.g. in context where you have let's say bunch of nodes e.g. in a data center, it would probably make sense... The point I'm driving is that before you stack anything one should know what the thing is and also what it isn't. Otherwise you are destined to end up with a mess :-)

Have been sick today so could not have concentrated to LKML, thus spamming here so that I can recall my thoughts.

We have a monthly call organized by @securepaul and with bunch of key Linux security contributors like @kees for instance, and at least one person I think from almost all major companies contributing to Linux. I think this topic should definitely end up to the next call's agenda.

@troglobit @kernellogger @torvalds The problem having just one LSM is that there's at least couple which have been invested a lot by companies. So thus next best thing is in my opinion the scope and constraint LSM better and "un-LSM" stuff that does not need to be LSM.

Having just one LSM is not something that we have privilege to decide anymore so better to work with the existing constrains.

@kernellogger @torvalds @troglobit I've already said too much here but I'll underline that in my opinion LSM's are important even tho they are not important in my *personal* desktop :-) Not bashing the tech at all, still I think that what is not LSM would rest of us understand the concept better than now, especially when it comes to stacking...

@kernellogger @torvalds @jarkko sorry, I’m not as well versed in this topic as the rest of you, evidently. Just wanted to give my 0.02€