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

KP Singh kpsingh at kernel.org
Thu Oct 5 14:12:56 UTC 2023


On Thu, Oct 5, 2023 at 11:48 AM José Bollo <jobol at nonadev.net> wrote:
>
> Le Wed, 27 Sep 2023 18:02:32 +0200,
> KP Singh <kpsingh at kernel.org> a écrit :
>
> > On Wed, Sep 27, 2023 at 5:09 PM Tetsuo Handa
> > <penguin-kernel at i-love.sakura.ne.jp> 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@kernel.org/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!



More information about the Linux-security-module-archive mailing list