[RFC PATCH 1/2] LSM: Allow dynamically appendable LSM modules.

[Tetsuo Handa]

On 2023/10/05 18:47, José Bollo wrote:
>> Now, comes the question of whether we need dynamically loaded LSMs, I
>> am not in favor of this. Please share your limitations of BPF as you
>> mentioned and what's missing to implement dynamic LSMs. My question
>> still remains unanswered.
>>
>> Until I hear the real limitations of using BPF, it's a NAK from me.
> 
> Hi all,
> 
> I don't understand the reason why you want to enforce implementers to
> use your BPF?

Because if whatever LSM modules were implemented using BPF, we won't need
to support LKM-based LSM. Supporting LKM-based LSM is expected because
the LSM community cannot accept whatever LSMs and the Linux distributor
cannot accept whatever LSMs.

> 
> Even if it can do any possible thing that security implementer wants,
> why enforcing to use it? For experimenting? But then after successful
> experimentation the implementer must translate to real LSM and rewrite
> almost every thing.

Not for experimenting. The advantage of implementing an LSM module using
BPF is that we can load that LSM without making that LSM module in-tree (i.e.
accepted by the LSM community) and built-in (i.e. accepted by the Linux
distributor). That is, the implementer will not try to rewrite a BPF-based
LSM to non BPF-based LSM if the implementer succeed to write that LSM using BPF.

But remaining out-of-tree (i.e. not accepted by the LSM community) might have
disadvantage that the BPF-based LSM is not identified as a LSM because the LSM ID
value won't be assigned. (I don't know where BPF-based LSMs are located in the
kernel source tree. All BPF-based LSMs except trivial examples included in the
kernel source tree will remain out-of-tree ?)

> 
> And also why to use faty BPF for a tricky simple stuff?