On 10/1/2023 4:31 AM, Tetsuo Handa wrote: > On 2023/09/28 1:37, Casey Schaufler wrote: >> On 9/27/2023 8:08 AM, Tetsuo Handa wrote: >>> Recently, the LSM community is trying to make drastic changes. >> I'd call them "significant" or "important" rather than "drastic". >> >>> Crispin Cowan has explained >>> >>> It is Linus' comments that spurred me to want to start this undertaking. He >>> observes that there are many different security approaches, each with their own >>> advocates. He doesn't want to arbitrate which of them should be "the" Linux >>> security approach, and would rather that Linux can support any of them. >>> >>> That is the purpose of this project: to allow Linux to support a variety of >>> security models, so that security developers don't have to have the "my dog's >>> bigger than your dog" argument, and users can choose the security model that >>> suits their needs. >>> >>> when the LSM project started [1]. >>> >>> However, Casey Schaufler is trying to make users difficult to choose the >>> security model that suits their needs, by requiring LSM ID value which is >>> assigned to only LSM modules that succeeded to become in-tree [2]. >> This statement is demonstrably false, and I'm tired of hearing it. > This statement is absolutely true. > > Kees Cook said there is no problem if the policy of assigning LSM ID value were > > 1) author: "Hello, here is a new LSM I'd like to upstream, here it is. I assigned > it the next LSM ID." > maintainer(s): "Okay, sounds good. *review*" > > 2) author: "Hello, here is an LSM that has been in active use at $Place, > and we have $Xxx many userspace applications that we cannot easily > rebuild. We used LSM ID $Value that is far away from the sequential > list of LSM IDs, and we'd really prefer to keep that assignment." > maintainer(s): "Okay, sounds good. *review*" > > and I agreed at https://lkml.kernel.org/r/6e1c25f5-b78c-8b4e-ddc3-484129c4c0ec@xxxxxxxxxxxxxxxxxxx . > > But Paul Moore's response was > > No LSM ID value is guaranteed until it is present in a tagged release > from Linus' tree, and once a LSM ID is present in a tagged release > from Linus' tree it should not change. That's *the* policy. > > which means that the policy is not what Kees Cook has said. > > >>> struct security_hook_heads security_hook_heads __ro_after_init; >>> +EXPORT_SYMBOL_GPL(security_hook_heads); >> Why disrupt the protection of security_hook_heads? You could easily add >> >> struct security_hook_heads security_loadable_hook_heads >> EXPORT_SYMBOL_GPL(security_loadable_hook_heads); >> >> and add the loaded hooks there. A system that does not use loadable >> modules would be unaffected by the ability to load modules. > > I'm fine if security_loadable_hook_heads() (and related code) cannot be > disabled by the kernel configuration. CONFIG_SECURITY ensures that you will be unhappy. Even setting that aside, it's the developer's job to sell the code to the communities involved. I could rant at certain distros for not including Smack, but until such time as I've made doing that attractive it really doesn't make any sense to do so. You don't think I've spent years on stacking because I want to run Android containers on Ubuntu, do you? > > Pasting https://lkml.org/lkml/2007/10/1/192 here again. > > On Mon, 1 Oct 2007, James Morris wrote: > > > > Merging Smack, however, would lock the kernel into the LSM API. > > Presently, as SELinux is the only in-tree user, LSM can still be removed. > > Hell f*cking NO! > > You security people are insane. I'm tired of this "only my version is > correct" crap. The whole and only point of LSM was to get away from that. > > And anybody who claims that there is "consensus" on SELinux is just in > denial. > > People are arguing against other peoples security on totally bogus points. > First it was AppArmor, now this. > > I guess I have to merge AppArmor and SMACK just to get this *disease* off > the table. You're acting like a string theorist, claiming that t here is > no other viable theory out there. Stop it. It's been going on for too damn > long. > > Linus > > The situation with LKM-based LSMs is symmetry of that post. > Those who are suspicious about supporting LKM-based LSMs is nothing but > > "Presently, as all in-tree users are built-in, LSM does not need to support LKM-based LSMs." > > . That's "only LSM modules which are built into vmlinux are correct" crap. > >> On a less happy note, you haven't addressed security blobs in any way. You >> need to provide a mechanism to allow an LSM to share security blobs with >> builtin LSMs and other loadable LSMs. > Not all LKM-based LSMs need to use security blobs. If you only want to support "minor" LSMs, those that don't use shared blobs, the loadable list implementation will suit you just fine. And because you won't be using any of the LSM infrastructure that needs the LSM ID, that won't be an issue. You can make something that will work. Whether you can sell it upstream will depend on any number of factors. But working code is always a great start. > What the LSM infrastructure > needs to do is manage which callback is called (so that undo operation is possible > when something went wrong while traversing the linked list). Everything else can > be managed by individual LSM implementations. >
