Re: LSM stacking in next for 6.1?

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.