[PATCH v38 04/39] LSM: Maintain a table of LSM attribute data

[Casey Schaufler]

On 10/23/2022 3:10 AM, Tetsuo Handa wrote:
> On 2022/10/23 16:27, Tetsuo Handa wrote:
>> On 2022/10/21 8:42, Casey Schaufler wrote:
>>> I will, on the other hand, listen to compelling arguments. It is not the
>>> intention of this code to lock out loadable modules. If I thought it would
>>> I would not have proposed it.
>> This code is exactly for locking out loadable modules.
>>
> Imagine a situation where two individuals independently develop their own
> web applications using the same identifier, and then their web applications
> started working together with other web applications using that identifier.
> When they published their web applications for public and wider use, a problem
> that both web applications are already using the same identifier arises.
> It is too late to reassign the identifier.
>
> The same trouble can happen with loadable LSM modules. Unless the upstream kernel
> behaves as if a DNS registerer that assigns a unique domainname for whatever web
> sites (regardless of whether a web site is for public or not), defining a permanent
> constant for LSM module is a way towards locking out loadable LSM modules. And it
> is well possible that a loadable LSM module wants to run on older kernels which
> do not have LSM id defined yet.
>
> This "define LSM id as userspace visible constant" is more dangerous than just
> reserving some space for future use. You are trying to control all IP addresses
> for the sake of only in-tree LSM modules. No, no, no, please don't do that...

It's really no more dangerous than using the LSM name. What if two developers
implement modules and both name it "belllapadula"? User space won't be able to
tell the difference if they base behavior on the module name. That's one thing
that a loadable module mechanism is going to need to address that a built-in
mechanism doesn't.