On Thu, Oct 5, 2023 at 11:48 AM José Bollo <jobol@xxxxxxxxxxx> wrote: > > Le Wed, 27 Sep 2023 18:02:32 +0200, > KP Singh <kpsingh@xxxxxxxxxx> a écrit : > > > On Wed, Sep 27, 2023 at 5:09 PM Tetsuo Handa > > <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > Recently, the LSM community is trying to make drastic changes. > > > > > > Crispin Cowan has explained > > > > > > It is Linus' comments that spurred me to want to start this > > > undertaking. He observes that there are many different security > > > approaches, each with their own advocates. He doesn't want to > > > arbitrate which of them should be "the" Linux security approach, > > > and would rather that Linux can support any of them. > > > > > > That is the purpose of this project: to allow Linux to support a > > > variety of security models, so that security developers don't have > > > to have the "my dog's bigger than your dog" argument, and users can > > > choose the security model that suits their needs. > > > > > > when the LSM project started [1]. > > > > > > However, Casey Schaufler is trying to make users difficult to > > > choose the security model that suits their needs, by requiring LSM > > > ID value which is assigned to only LSM modules that succeeded to > > > become in-tree [2]. Therefore, I'm asking Casey and Paul Moore to > > > change their mind to allow assigning LSM ID value to any LSM > > > modules (so that users can choose the security model that suits > > > their needs) [3]. > > > > > > I expect that LSM ID value will be assigned to any publicly > > > available LSM modules. Otherwise, it is mostly pointless to propose > > > this patch; there will be little LSM modules to built into vmlinux; > > > let alone dynamically loading as LKM-based LSMs. > > > > > > Also, KP Singh is trying to replace the linked list with static > > > calls in order to reduce overhead of indirect calls [4]. However, > > > this change assumed that any LSM modules are built-in. I don't like > > > such assumption because I still consider that LSM modules which are > > > not built into vmlinux will be wanted by users [5]. > > > > > > Then, Casey told me to supply my implementation of loadable security > > > modules [6]. Therefore, I post this patch as basic changes needed > > > for allowing dynamically appendable LSM modules (and an example of > > > appendable LSM modules). This patch was tested on only x86_64. > > > > > > Question for KP Singh would be how can we allow dynamically > > > appendable LSM modules if current linked list is replaced with > > > static calls with minimal-sized array... > > > > As I suggested in the other thread: > > > > https://lore.kernel.org/bpf/20230918212459.1937798-1-kpsingh@xxxxxxxxxx/T/#md21b9d9cc769f39e451d20364857b693d3fcb587 > > > > You can add extra static call slots and fallback to a linked list > > based implementation if you have more than say N modules [1] and > > fallback to a linked list implementation [2]. > > > > for [1] you can just do MAX_LSM_COUNT you can just do: > > > > #ifdef CONFIG_MODULAR_LSM > > #define MODULAR_LSM_ENABLED "1,1,1,1" > > #endif > > > > and use it in the LSM_COUNT. > > > > for [2] you can choose to export a better module API than directly > > exposing security_hook_heads. > > > > 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? > > 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. > > And also why to use faty BPF for a tricky simple stuff? > faty BPF? I am not even sure what that means? BPF is compiled to native code and is used in production systems and not just experimental stuff. I think you have some catching up to do here!
