On 2022/09/09 3:52, Paul Moore wrote: > At least one of those, Landlock, has been merged upstream and is now > available in modern released Linux Kernels. As far as the other LSMs > are concerned, I don't recall there ever being significant interest > among other developers or users to warrant their inclusion upstream. > If the authors believe that has changed, or is simply not true, they > are always welcome to post their patches again for discussion, review, > and potential upstreaming. However, I will caution that it is > becoming increasingly difficult for people to find time to review > potential new LSMs so it may a while to attract sufficient comments > and feedback. Inclusion into upstream is far from the goal. > As has been discussed before, this isn't so much an issue with the > __ro_after_init change, it's really more of an issue of running > out-of-tree kernel code on pre-built distribution kernels, with > "pre-built" being the most important part. It is my understanding > that if the user/developer built their own patched kernel this would > not likely be an issue as the out-of-tree LSM could be patched into > the kernel source. There always is LSM module which is not enabled in pre-built distribution kernels. https://bugzilla.redhat.com/show_bug.cgi?id=542986 Even if source code is already available in distribution kernels, as long as distribution refuses to include into pre-built distribution kernels, it is no different from the out-of-tree LSM. The user/developer has to rebuild the whole distribution kernels is an unacceptable barrier. > The problem comes when the user/developer wants to > dynamically load their out-of-tree LSM into a pre-built distribution > kernel, presumably to preserve a level of distribution support. Not only for preserving the level of distribution support. But also for allowing immediate updates whenever distribution kernels are updated, and allowing out of kernel modules (e.g. from AntiVirus, hardware vendors) to be loaded into pre-built distribution kernels (instead of user/developer rebuilt distribution kernels). > Unfortunately, to the best of my knowledge, none of the major > enterprise Linux distributions will provide support for arbitrary > third-party kernel modules (it may work, but if something fails the > user is on their own to triage and resolve). I know it, especially Red Hat is strict regarding that. Red Hat does not provide support for rebuilt kernels even with zero changes (e.g. same kernel source code, same kernel configuration). Some hardware vendors provide support for their device drivers when used with RHEL kernel but does not provide support when used with CentOS kernel (not CentOS Stream), despite there is effectively no difference. Being able to continue using pre-built distribution kernels is a fatal requirement for users. > > Beyond the support issue, there are likely to be other problems as > well since the kernel interfaces, including the LSM hooks themselves, > are not guaranteed to be stable across kernel releases. That's not a big problem. Loadable LSM modules will be updated as the kernel interfaces change. But the combination of "the kernel interfaces does not legally allow loadable LSM modules" and "distributors do not enable LSMs already available in upstream kernels" and "it is becoming increasingly difficult for people to find time to review potential new LSMs" and "it is difficult for users/developers to continue rebuilding distributor kernels only for enabling LSMs" indicates there is no space for LSMs which are not enabled in pre-built distribution kernels to survive; it is tantamount to a death sentence. Legally allowing loadable LSM modules is an answer to current situation. > >> Last 10 years, my involvement with Linux kernel is "fixing bugs" rather than >> "developing security mechanisms". Changes what I found in the past 10 years are: >> >> As far as I'm aware, more than 99% of systems still disable SELinux. > > I would challenge you to support that claim with data. Unfortunately, that's an impossible request for me. I worked at a support center for three years, and I found (from e.g. sosreport) that no system enabled SELinux. Since I already left the support center, I'm no longer in a position who can collect statistic data. > Granted, we > are coming from very different LSM backgrounds, but I find that number > very suspect. It has been several years since I last looked, but I > believe the latest published Android numbers would give some support > to the idea that more than 1% of SELinux based systems are running in > enforcing (or permissive) mode. Significantly more. In know-how manuals developed by the support center, disabling SELinux is the first action after installation, and people using the support center follow it. (I personally feel that using SELinux with targeted policy is possible. But they hate troubles caused by unwanted functionality. And they can't afford keeping SELinux enabled because nobody can adjust policy for their servers. If troubles caused by SELinux happen, even I won't be able to provide support because I'm not in a position to understand and manage the details/usage of their servers.) You might wonder how they are protecting their servers without SELinux. It is a mystery. But I if recall the days at the support center, I seldom saw servers which directly face the Internet. Maybe they are using security appliance for servers facing the Internet, and using RHEL for servers in already secured environment. Then, the need to enable SELinux remains still low sounds realistic. For example, telnet and ftp are used even nowadays in some systems. https://bugzilla.redhat.com/show_bug.cgi?id=1853102 https://bugzilla.redhat.com/show_bug.cgi?id=1914536 But again, I'm not in a position for collecting statistic data. > >> People use RHEL, >> but the reason to choose RHEL is not because RHEL supports SELinux. > > Once again, if you are going to make strong claims such as this, > please provide data. I know of several RHEL users that are only able > to run SELinux based systems as it is the only LSM which meets their > security requirements. Sure, there are systems where SELinux is the only choice. But surely there are systems where SELinux is not the only choice. > I would caution against confusing the security policy driven access > controls provided by many in-tree LSMs with out-of-tree antivirus > software. They have different goals, different use cases, and > different user groups (markets). But due to the above-mentioned death sentence, we currently can't allow users/developers to use different LSMs which have different goals, different use cases, and different user groups (markets). Very bad...
