LSM stacking in next for 6.1?

[Casey Schaufler]

On 10/25/2022 3:12 PM, Tetsuo Handa wrote:
> On 2022/10/25 23:12, Casey Schaufler wrote:
>> 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.
>>
> As an easy example, please show me an eBPF program that allows restricting where
> to chroot to and allows configuring where to chroot to using /sys/kernel/security/
> interface.
>
> An loadable LSM consists of hooks (for filtering access requests) and interface
> (for configuring rules whether to filter access requests).
>
> Your LSM id approach makes it impossible to use interface (due to lack of LSM id
> for loadable LSM modules) by loadable LSM modules. LSM id must not be limited to
> built-in LSM modules.

I'm sorry that I am failing to communicate my understanding of why this
isn't true. You need a built-in LSM that loads and manages loadable
security modules. That LSM would have an LSM ID just like the BPF LSM
has a LSM ID. I have no doubt that there are multiple workable implementations,
as I have looked into many different ways to implement the stacking for
built-in modules. I am also sorry that I don't expect to have enough working
years left to even consider spending any more time on the problem. This is
a development effort for The Next Generation.