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

[Tetsuo Handa]

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