Re: LSM stacking in next for 6.1?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux