[RFC PATCH 1/2] LSM: Allow dynamically appendable LSM modules.

Tetsuo Handa penguin-kernel at I-love.SAKURA.ne.jp
Sat Oct 21 12:21:02 UTC 2023


On 2023/10/21 5:40, Casey Schaufler wrote:
>>> You can make something that will work. Whether you can sell it upstream will
>>> depend on any number of factors. But working code is always a great start.
>> Selling a code to the upstream is not sufficient for allowing end users to use
>> that code.
>>
>> For https://bugzilla.redhat.com/show_bug.cgi?id=542986 case, the reason that Red Hat
>> does not enable Smack/TOMOYO/AppArmor is NOT "Smack/TOMOYO/AppArmor are not attractive".
> 
> And YAMA is enabled because it *is* attractive to RedHat's support based business
> model. Even if we did have loadable LSM support I doubt RedHat would even consider
> enabling it. Their model is based on selling support.

I don't expect that Red Hat will enable other LSMs as soon as we made it possible to use
other LSMs via LKM. But making it possible to use other LSMs at user's own risk via LKM
(like device/filesystem drivers) is the first step towards enabling other LSMs.

Somebody other than Red Hat can establish a business model for supporting other LSMs. But
current situation (i.e. requiring replacement of vmlinux ) can not allow such somebody to
establish a business model for supporting other LSMs. What is important is "don't make
LKM-based LSMs conditional (e.g. don't require kernel config option to enable LKM-based
LSMs, unlike device/filesystem drivers can be loaded as long as CONFIG_MODULES=y ).



More information about the Linux-security-module-archive mailing list