11:03 p.m.
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.