LSM stacking in next for 6.1?

[Tetsuo Handa]

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@woody.linux-foundation.org .

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@namei.org/ .

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...