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.
