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

[Casey Schaufler]

On 10/4/2023 3:40 AM, Tetsuo Handa wrote:
> On 2023/10/02 0:19, Casey Schaufler wrote:
>>> I'm fine if security_loadable_hook_heads() (and related code) cannot be
>>> disabled by the kernel configuration.
>> CONFIG_SECURITY ensures that you will be unhappy.
> I don't care about Linux distributors who chose CONFIG_SECURITY=n in their
> kernel configurations. What I'm saying is that security_loadable_hook_heads
> (and related code) do not depend on some build-time configuration. Also, I
> don't care about Linux distributors who patch their kernel source code in
> order to remove security_loadable_hook_heads (and related code) before
> building their kernels.
>
> But if a kernel is targeted for specific environment where out-of-tree LKMs
> (e.g. storage driver, filesystems) are not required, the person/organization
> who builds that kernel can protect that kernel from out-of-tree LKMs
> (including LKM-based LSMs) by enforcing module signing functionality.
>
> Also if a kernel is ultimately targeted for specific environment where LKM
> support is not required, the person/organization who builds that kernel can
> protect that kernel from out-of-tree LKMs (including LKM-based LSMs) by
> disabling loadable module functionality.
>
> Linux distributors that I want to run LSMs are generally trying to support
> as much users/environments as possible. The combination of enabling loadable
> module functionality and not enforcing module signing functionality is a good
> balance for that purpose.
>
>> Even setting that aside, it's the developer's job to sell the code to
>> the communities involved. I could rant at certain distros for not including
>> Smack, but until such time as I've made doing that attractive it really
>> doesn't make any sense to do so. You don't think I've spent years on stacking
>> because I want to run Android containers on Ubuntu, do you?
> Which one ("the LSM community" or "the Linux distributors") do you mean by
> "the communities involved" ?

There's a reason I used the plural "communities" instead of the singular
"community". In the case of loadable LSMs we're talking about *at least*
the LSM developers, Linux distributors, networking developers, the performance
crowd, all those people wound up in secure/trusted boot, API and real-time.

> For out-of-tree LKMs (e.g. storage driver, filesystems) that can be loaded as
> a loadable kernel module, the provider/developer can directly sell the code to
> end users (i.e. they can sell without being accepted by the upstream Linux
> community and being enabled by the Linux distributors' kernel configurations).
>
> But for out-of-tree LSMs that cannot be loaded as a loadable kernel module,
> the provider/developer currently cannot directly sell the code to end users.
>
> You said
>
>   This makes it sound like LSMs are always developed for corporate use.
>   While that is generally true, we should acknowledge that the "sponsor"
>   of an LSM could be a corporation/government, a foundation or a hobbyist.
>   A large, comprehensive LSM from a billion dollar corporation in support
>   of a specific product should require more commitment than a small, targeted
>   LSM of general interest from joe at schlobotnit.org. I trust that we would
>   have the wisdom to make such a distinction, but I don't think we want to
>   scare off developers by making it sound like an LSM is something that only
>   a corporation can provide a support plan for.
>
> at https://lkml.kernel.org/r/847729f6-99a6-168e-92a6-b1cff1e6b97f@schaufler-ca.com .
>
> But "it's the developer's job to sell the code to the communities involved" is
> too hard for alone developer who can write a code and provide support for that code
> but cannot afford doing activities for selling that code (e.g. limited involvement
> with communities).
>
> Your "it's the developer's job" comment sounds like "LSMs are always developed by
> those corporation/government who has much involvement with communities" which
> scares off developers who can't afford doing activities for selling that code.

Sorry, but you've chosen the wrong person to present that argument to.
Smack was developed without any corporate, government or foundation support.
I wrote it in a theater green room  during rehearsals for a production of
"Madmoiselle Modiste". It has, from time to time, received corporate support,
but is currently completely self funded. Yes, it's hard. Yes, the commitment
could well scare off many developers. If you want easy, create websites.

>
>>>> On a less happy note, you haven't addressed security blobs in any way. You
>>>> need to provide a mechanism to allow an LSM to share security blobs with
>>>> builtin LSMs and other loadable LSMs.
>>> Not all LKM-based LSMs need to use security blobs.
>> If you only want to support "minor" LSMs, those that don't use shared blobs,
>> the loadable list implementation will suit you just fine. And because you won't
>> be using any of the LSM infrastructure that needs the LSM ID, that won't be
>> an issue.
> Minor LSMs can work without using shared blobs managed by the LSM infrastructure.
> AKARI/CaitSith are LKM-based LSMs that do not need to use shared blobs managed by
> the LSM infrastructure. TOMOYO does not need an LSM ID value, but you are trying
> to make an LSM ID mandatory for using the LSM infrastructure.
>
>> 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 "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.

> After all, requiring any LSMs to be built-in is an unreasonable barrier compared to
> other LKMs (e.g. storage driver, filesystems).
>