Re: LSM stacking in next for 6.1?

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

On 2022/10/28 19:14, John Johansen wrote:
> On 10/26/22 03:19, Tetsuo Handa wrote:
>> On 2022/10/26 7:41, Casey Schaufler wrote:
>>>              You need a built-in LSM that loads and manages loadable
>>> security modules.
>>
>> That is no longer loadable LSM modules. A loadable LSM module must be capable of
>> loading any code and using any interface that is allowed to loadable kernel modules
>> using /sbin/insmod command. That is my understanding of what you have promised (and
>> the reason I am allowing you to continue working on LSM stacking before I make
>> CONFIG_SECURITY_TOMOYO=m).
>>
> 
> Tetsuo, think of it this way. LSM stacking is going to make it much easier for new
> LSM modules because they won't automatically be excluded because one of the other
> LSMs is needed.
> 
> The problem of loadable LSM modules is orthogonal, and Casey shouldn't need to
> solve it in this patch series. That is further work to be taken up by another,
> as Casey has clearly stated its work he is not interested in doing.
> 
> However the real problem you are trying to solve won't be solved by loadable LSM
> modules, though they may help. Just having loadable LSMs modules won't mean a
> distro will build an LSM as a loadable module instead of disabling it, nor does
> it mean a distro will allow loading an out of tree LSM module. Even if the
> upstream kernel doesn't provide an option to block loading them, distros will.
> 

What do you think the background of

  Ultimately the challenge is getting userspace developers to accept a
  change that is not part of the upstream Linux Kernel and thus not
  guaranteed under the usual "don't break userspace" kernel API promise.

is? I consider that the reason is because

  We do care about userspace programs and users who are using userspace programs.

. If we don't care about userspace and users, we would not mind breaking APIs.
This reasoning is more stronger than "we don't care about out-of-tree code"
reasoning.

Distributors have rights to block loading loadable kernel modules which are
not included in upstream kernels. But for example Red Hat is not excising
the rights to block loading loadable kernel modules (e.g.
https://access.redhat.com/solutions/1376133 ). What do you think about the
reasons of not blocking loading loadable kernel modules which are not included
in upstream kernels? I consider that the reason is because

  Allowing loadable kernel modules which cannot be supported by distributors
  to exist and to be loaded into distributor kernels is more beneficial for
  users.

That is, we have been allowing out-of-tree kernel code to exist because
out-of-tree kernel code can be beneficial for users despite distributors cannot
afford supporting out-of-tree kernel code.

If you really think that we have the rights to lock out out-of-tree kernel code
and/or disable loading of out-of-tree kernel code via /sbin/insmod, firstly achieve

  (1) Disallow loading of non-GPL kernel modules. (It is a trivial change.)

  (2) Disallow loading of out-of-tree kernel code via /sbin/insmod .
      (I don't know how we can technically enforce such change. Unlike not assigning
      LSM id value to LSM modules, we need to somehow be able to check whether an
      arbitrary file is in-tree (e.g. forbid "git add some_file") and unmodified
      (e.g. forbid "patch -p1 < some_patch").

before you enforce requiring an LSM id value in order to register an LSM module.
I don't accept "I'm not interested in making such changes". It is your duty to
achieve if you use "we don't care about out-of-tree code" as a rationale for
requiring an LSM id value in order to register an LSM module.

Nowadays, many software is developed using programming languages which can generate code
for multiple operating systems. That is, people are getting indifferent with operating
systems they run their software. Then, what is an advantage of choosing Linux as operating
systems for running their software, if Linux kernel does not provide freedom for
customization depending on user's needs?

As web application developers increases, developers who can understand C language (and
system call) are decreasing. As a result, it is getting more and more difficult to let them
understand and manage fine-grained allowlisting-based access controls like SELinux. Then,
what is an advantage of choosing Linux as operating systems for running their software, if
LSM does not provide freedom for using whatever simpler LSM modules users want?

Windows operating system provides WSL (Windows Subsystem for Linux) which allows running
CUI programs and servers which are designed for Linux. Windows users can run CUI programs
and servers without requiring real Linux kernels and can run GUI programs via Windows
kernels. Neither SELinux nor AppArmor is required for protecting programs/servers, for
antivirus software for Windows will provide protection. Then, what is an advantage of using
real Linux kernels, if we cannot allow Linux kernels to use whatever LSM modules users want?

I believe that it is time to get out of "we don't care about out-of-tree code".
The "we don't care about out-of-tree code" reasoning is a brain freeze that leads to
forget about users who still continue using Linux as platform for running their software.