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...
.
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/00...
caused by
https://patchwork.kernel.org/project/linux-security-module/patch/alpine.L...
.
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...