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.
