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.