Re: LSM stacking in next for 6.1?

[John Johansen <john.johansen@canonical.com>]

On 9/15/22 07:27, Tetsuo Handa wrote:
> 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.
> 

I am sympathetic, I want this too. But RH choices are not a technical problem,
they could easily enable and not support other LSMs (eg. Ubuntu does). It is a
political problem and I don't see loadable LSMs changing this.