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" ?
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@xxxxxxxxxxxxxxx. 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@xxxxxxxxxxxxxxxx .
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.
>>> 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".
After all, requiring any LSMs to be built-in is an unreasonable barrier compared to
other LKMs (e.g. storage driver, filesystems).
