On Thu, Sep 8, 2022 at 11:19 AM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > On 2022/08/03 9:01, Casey Schaufler wrote: > > I would like very much to get v38 or v39 of the LSM stacking for Apparmor > > patch set in the LSM next branch for 6.1. The audit changes have polished > > up nicely and I believe that all comments on the integrity code have been > > addressed. The interface_lsm mechanism has been beaten to a frothy peak. > > There are serious binder changes, but I think they address issues beyond > > the needs of stacking. Changes outside these areas are pretty well limited > > to LSM interface improvements. > Many modules > > SimpleFlow （ 2016/04/21 https://lwn.net/Articles/684825/ ） > HardChroot （ 2016/07/29 https://lwn.net/Articles/695984/ ） > Checmate （ 2016/08/04 https://lwn.net/Articles/696344/ ） > LandLock （ 2016/08/25 https://lwn.net/Articles/698226/ ） > PTAGS （ 2016/09/29 https://lwn.net/Articles/702639/ ） > CaitSith （ 2016/10/21 https://lwn.net/Articles/704262/ ） > SafeName （ 2016/05/03 https://lwn.net/Articles/686021/ ） > WhiteEgret （ 2017/05/30 https://lwn.net/Articles/724192/ ） > shebang （ 2017/06/09 https://lwn.net/Articles/725285/ ） > S.A.R.A. （ 2017/06/13 https://lwn.net/Articles/725230/ ） > > are proposed 5 or 6 years ago, but mostly became silent... 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. > I still need byte-code analysis for finding the hook and code for making the hook > writable in AKARI/CaitSith due to lack of EXPORT_SYMBOL_GPL(security_add_hooks). > I wonder when I can stop questions like https://osdn.net/projects/tomoyo/lists/archive/users-en/2022-September/000740.html > caused by https://patchwork.kernel.org/project/linux-security-module/patch/alpine.LRH.2.20.1702131631490.8914@xxxxxxxxx/ . 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. 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. 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). 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. > 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. 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. > 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. > Instead, Ubuntu users are increasing, but the reason people choose Ubuntu is not because > Ubuntu supports AppArmor. Maybe because easy to use container environment. Maybe because > available as Windows Subsystem for Linux. I suspect IBM/RH's decision to change CentOS' relationship to RHEL also resulted in a number of users moving to Ubuntu, and that has nothing to do with the LSMs. > However, in many cases, it seems that whether the OS is Windows or Linux no longer > matters. Programs are written using frameworks/languages which developers hardly care > about Windows API or Linux syscall. LSM significantly focuses on syscalls, but the > trend might no longer be trying to solve in the LSM layer... Every LSM is different, that is partly why it is so interesting as a security framework. Look at Yama, look at AppArmor, look at Smack, look at the BPF LSM ... there is no one security model, and claiming that the LSM focuses on syscalls is misleading. If you had to pick only one concept that the LSM focuses on, I believe it would be providing visibility and access controls for security relevant interactions between entities on the system. Processes opening files, processes executing other processes, processes talking to each other both across the network and on the local system. Some of these things involve syscalls, but as most of us know, making meaningful access control decisions often involves much more than just the syscall. > Also, Linux servers started using AntiVirus software. Enterprise AntiVirus software uses > loadable kernel module that rewrites system call table rather than using LSM interface. > It seems that people prefer out-of-the-box security over fine grained access control rule > based security. 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). I think that is about the nicest thing I can think to say about those antivirus products ;) -- paul-moore.com
