LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/29 2:40, Kees Cook wrote:
> On Fri, Oct 28, 2022 at 10:58:30PM +0900, Tetsuo Handa wrote:
>> I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
>> which could not get merged upstream or supported by distributors, for patching and
>> rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
>> LSMs is already a lot of barrier for users. But requiring a permanent integer in
>> order to use a LSM module is a denial of even patching and rebuilding the whole
>> kernel. That's why I hate this change.
> 
> But the upstream kernel _does not support APIs for out-of-tree code_. To
> that point, security_add_hooks() is _not exported_, so it is already not
> possible to create a modular LSM without patching the kernel source.

AKARI/CaitSith and several other LSM modules are running without patching
the kernel source. But this patchset makes it impossible to use 9 out of 13
LSM modules as (not upstreamed but) built-in LSM modules by patching the kernel,
due to lack of identifier. That's a needless requirement that harms development
of LSM modules.

Linux kernel has started using a new and more inclusive terminology for the
Linux kernel code and documentation. But this patchset is making the code
more and more exclusive. That's a way to exclude LSM modules that satisfies
user's need, even if perfect LSM stacking implementation is provided.

What do you think if an authority commands you that companies like Intel, Google,
RedHat, Canonical etc. must wind up because these companies are not member of
that authority? That's behavior of autocracy.

This patchset _does not allow out-of-tree code to exist_ rather than simply
_does not support APIs for out-of-tree code_. The behavior of this patchset is
to exclude 9 out of 13 LSM modules, unless upstream kernel allows these modules
to exist (by assigning an LSM id value). What a closed community LSM is!