On Mon, Oct 2, 2023 at 12:56 PM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > On 2023/10/02 0:00, Casey Schaufler wrote: > > On 10/1/2023 3:51 AM, Tetsuo Handa wrote: > >> On 2023/09/25 20:22, KP Singh wrote: > >>>> It is Casey's commitment that the LSM infrastructure will not forbid LKM-based LSMs. > >>>> We will start allowing LKM-based LSMs. But it is not clear how we can make it possible to > >>>> allow LKM-based LSMs. > >>> I think this needs to be discussed if and when we allow LKM based LSMs. > >> It is *now* (i.e. before your proposal is accepted) that we need to discuss. > >> > >>> One needs to know MAX_LSM_COUNT at compile time (not via kernel > >>> command line), I really suggest you try out your suggestions before > >>> posting them. I had explained this to you earlier, you still chose to > >>> ignore and keep suggesting stuff that does not work. > >> Your proposal needs to know MAX_LSM_COUNT at compile time, that's why > >> we need to discuss now. > >> > >>> We will see when this happens. I don't think it's a difficult problem > >>> and there are many ways to implement this: > >>> > >>> * Add a new slot(s) for modular LSMs (One can add up to N fast modular LSMs) > >>> * Fallback to a linked list for modular LSMs, that's not a complexity. > >>> There are serious performance gains and I think it's a fair trade-off. > >>> This isn't even complex. > >> That won't help at all. > > > > This is exactly the solution I have been contemplating since this > > discussion began. It will address the bulk of the issue. I'm almost > > mad/crazy enough to produce the patch to demonstrate it. Almost. > > Yes, please show us one. I'm fine if the mechanism which allows LKM-based LSMs > cannot be disabled via the kernel configuration options. > > I really want a commitment that none of the LSM community objects revival of > LKM-based LSMs. I'm worrying that some of the LSM community objects revival of > LKM-based LSMs because adding extra slots and/or linked list is e.g. an overhead, > increases attack surface etc. > > Let's consider the Microsoft Windows operating system. Many security vendors are > offering security software which can run without recompiling the Windows OS. > > But what about Linux? Security vendors cannot trivially add a security mechanism > because LKM-based LSMs are not supported since 2.6.24. As a result, some chose > hijacking LSM hooks, and others chose overwriting system call tables. > > The Linux kernel is there for providing what the user needs. What about the LSM > infrastructure? The LSM infrastructure is too much evolving towards in-tree and > built-in security mechanisms. > > The consequence of such evolving will be "Limited Security Modes" where users cannot > use what they need. New ideas cannot be easily tried if rebuild of vmlinux is > inevitable, which will also prevent a breath of fresh ideas from reaching the LSM > community. > > Never "discussed *if* we allow LKM based LSMs", for the LSM community cannot > afford accepting whatever LSMs and the Linux distributors cannot afford enabling > whatever LSMs. > > I'm not speaking for the security vendors. I'm speaking from the point of view of > minority/out-of-tree users. > > > There are still a bunch of details (e.g. shared blobs) that it doesn't > > address. On the other hand, your memory management magic doesn't > > address those issues either. > > Security is always trial-and-error. Just give all Linux users chances to continue > trial-and-error. You don't need to forbid LKM-based LSMs just because blob management > is not addressed. Please open the LSM infrastructure to anyone. It already is, the community is already using BPF LSM. e.g. https://github.com/linux-lock/bpflock >
