LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/09/15 0:50, Casey Schaufler wrote:
> On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
>> Please distinguish the difference between "enable" and "support" at
>> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
>> I hate the word "support", for nobody can share agreed definition.)
>>
>> "enable" is something like "available", "allow to exist".
>>
>> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>>
>> However, in the Red Hat's world, "enable" == "support". The kernel config options
>> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
>> cannot support cannot be enabled by Red Hat.
> 
> The "enable" == "support" model in consistent with the expectations of
> paying customers. 

Regarding CONFIG_MODULES=y,
"Vendor-A enables module-A" == "Vendor-A provides support for module-A" and
"Vendor-B enables module-B" == "Vendor-B provides support for module-B".

Regarding CONFIG_SECURITY=y (namely in the RH world),
"Distributor-A enables LSM-A" == "Distributor-A provides support for LSM-A".
However, "Distributor-A does not enable LSM-B" == "Some vendor is impossible to
provide support for LSM-B".

"Distributor-A does not enable module-B" == "Distributor-A is not responsible for
providing support for module-B" and "Vendor-B enables LSM-B" == "Vendor-B provides
support for LSM-B" are what I expect.

Current LSM interface does not allow LSM-B to exist in Distributor-A's systems.
The "enable" == "support" model should be allowed for LSM interface as well.
What a strange asymmetry rule!



>> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
>> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
>> as a loadable module LSM (so that TOMOYO can be used without the "support" by
>> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
>> other than SELinux.
> 
> That is correct. Redhat has chosen to support only SELinux. If you want
> TOMOYO to be enabled in a distribution you need to sell the value to a
> distributor (really, really hard) Or (not recommended) become one yourself.

What I'm asking is "allow non-SELinux to exist in RH systems".
I'm not asking RH to "provide efforts for fixing non-SELinux".
Being able to build in-tree version of TOMOYO via "make M=security/tomoyo"
releases RH from the "enable" == "support" spell.