[PATCH 04/10] CaitSith: Add header file.

[Tetsuo Handa]

On 2022/11/05 11:43, Serge E. Hallyn wrote:
> On Wed, Nov 02, 2022 at 10:57:48AM -0700, Casey Schaufler wrote:
>> On 11/2/2022 10:10 AM, Tetsuo Handa wrote:
>>> The main point of this submission is to demonstrate how an LSM module
>>> which can be loaded using /sbin/insmod can work, and to provide
>>> consideration points for making changes for LSM stacking in a way that
>>> will not lock out LSM modules which can be loaded using /sbin/insmod .
>>
>> CaitSith could readily be done as an in-tree LSM. The implementation
>> of loadable module infrastructure is unnecessary.
> 
> Sorry, I'm getting confused.  But in-tree and loadable are not related,
> right?

Very much related. My goal is to get CaitSith in-tree as a loadable LSM module
which can be loaded using /sbin/insmod .

Lessons I learned from TOMOYO are that:

  Most of Linux users, unlike Linux kernel developers, consider the Linux kernel
  as something black-box program. While the source code is open, they cannot
  afford understanding how updating the Linux kernel via "yum update" or
  "apt dist-upgrade" affects their systems.

  I can't force Linux users to replace their kernel packages in order to
  allow them to use TOMOYO, for replacing the kernel package makes their
  replaced kernel packages incompatible (kABI breakage) with other kernel
  modules (e.g. device drivers provided by hardware vendors) and/or makes
  their kernel completely unsupported. I can support TOMOYO part but I can't
  support the rest of the kernel, which makes it impossible for Linux users
  using supported kernels to try TOMOYO. Being in-tree helps catching up
  the upstream kernel changes, but being in-tree does not help allowing
  Linux distribution users to use TOMOYO.

  Linux distributors cannot afford enabling all LSM modules, due to the
  "enabled" == "supported" spell. There are out-of-tree kernel modules
  which are built as a loadable kernel module (i.e. not included into
  the main kernel package which is supported by Linux distributors), but
  the LSM framework does not legally allow use of LSM modules which are
  not built into the bzImage file.

If the LSM framework legally allows use of LSM modules which are not built
into the bzImage file, we can allow users to use whatever LSM modules they
want (and "support" is provided by the module authors rather than by Linux
distributors).

This submission is to ask LSM framework "please don't make it impossible to
allow users to use whatever LSM modules they want". That is more important
than "complete LSM stacking".

Casey's proposal towards "complete LSM stacking" is making it impossible to
allow users to use whatever LSM modules they want, due to the requirement of
having an LSM id integer value and using fixed sized array.