Re: LSM stacking in next for 6.1?
On 10/25/2022 4:20 AM, Tetsuo Handa wrote:
On 2022/10/25 19:26, John Johansen wrote:
> no, Casey is not. He is trying to find a path forward to get LSM
> stacking upstream sooner than later. He has made proposals that
> admittedly you have not liked, but he has at least tried to propose
> ideas that could work within the insane set of constraints.
I'm OK with getting LSM stacking upstream. But changes made based on
only built-in modules are bad. If LSM id cannot be assigned to loadable
LSM modules at runtime because not all loadable LSM modules will be
in-tree in order to get an LSM id assigned, loadable LSM modules won't
be able to utilize e.g. lsm_module_list system call (or whatever
changes made while trying to unshare resources/interfaces currently
shared among SELinux/Smack/AppArmor).
It will be a complete reinvention of Linux security framework which is
merely borrowing hooks provided by LSM. That is no different from
duplicating existing LSM hooks and managing via completely different
set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
/sys/kernel/security2/$lsmname/$filename ). Such implementation is
no longer loadable LSM. It is LSM version 2. And I don't think that
such implementation will be accepted unless you agree to kill current
LSM (say, LSM version 1).
The counter argument to this statement is that BPF has been accepted
upstream. eBPF programs are different from built-in security modules.
There is no reason that a well implemented LSM that accepts loadable
modules *that are different* from built-in modules couldn't be created.
I seriously doubt that it would get upstream for all the reasons
usually cited. But there is nothing about the implementation I've proposed
that would prevent it.