[PATCH] LSM: allow loadable kernel module based LSM modules
Tetsuo Handa
penguin-kernel at I-love.SAKURA.ne.jp
Fri Sep 6 10:55:30 UTC 2024
On 2024/09/06 16:43, Tetsuo Handa wrote:
> On 2024/09/04 23:23, Paul Moore wrote:
>> Patches that add complexity to the LSM framework without any benefit
>> to the upstream, in-tree LSMs, or the upstream kernel in general, are
>> not good candidates for inclusion in the upstream kernel.
This patch adds a clear value for Linux users that people get more chances to
use LSM modules which match their needs.
Quoting from [1]:
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!
Your "any benefit to in-tree LSMs" is completely ignoring Linux users.
LSM is for all Linux users, LSM is not only for LSM developers.
Link: https://lkml.kernel.org/r/c2a3279d-451d-23df-0911-e545d21492e6@I-love.SAKURA.ne.jp [1]
More information about the Linux-security-module-archive
mailing list