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?
