[RFC PATCH 1/2] LSM: Allow dynamically appendable LSM modules.

[Tetsuo Handa]

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@I-love.SAKURA.ne.jp .

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.

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