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. > After ((SELinux xor Smack) and AppArmor) is made possible in next for 6.1, what comes next? Are you planning to make (SELinux and Smack and AppArmor) possible? My concern is, when loadable LSM modules becomes legal, for I'm refraining from again proposing CaitSith until LSM stacking completes. Linus Torvalds said You security people are insane. I'm tired of this "only my version is correct" crap. at https://lkml.kernel.org/r/alpine.LFD.0.999.0710010803280.3579@xxxxxxxxxxxxxxxxxxxxxxxxxx . 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... 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/ . 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. People use RHEL, but the reason to choose RHEL is not because RHEL supports SELinux. The only thing changed is that the way to disable SELinux changed from SELINUX=disabled in /etc/selinux/config to selinux=0 on kernel command line options. 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. 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... 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. In other words, it seems that allowlist based LSM modules are too difficult for normal users. Maybe it is better for normal users to develop and use single-function LSMs than try to utilize ((SELinux xor Smack) and AppArmor)... But still loadable LSM modules are not legally available...
