On Sun, Oct 1, 2023 at 12:51 PM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> 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. People already mention that you seem to deliberately ignore advice given to you and continue with your own narrative. Here's my last attempt to explain things to you: You are conflating two use cases, built-in out-of-tree LSMS and modular LSMs. However, the proposed changes block neither of the use cases. * For modules that are out-of-tree but compiled into the kernel, they can just modify the MAX_LSM_COUNT * For dynamically loadable LSMs, you anyways want a separate security_hook_heads. The __ro_after_init should not be relaxed on the existing security_hook_heads to prevent any memory corruption from overriding LSM callbacks, this lowers the existing security posture. And then, in the call_int_hook and security_for_each_hook you can iterate over both the static call slots. ^^ I said the above multiple times but you ignored all of it! - KP > > > 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. You became so blind because what you want to use (i.e. > SELinux and BPF) are already supported by Linux distributors. The reason I'm > insisting on supporting LKM-based LSMs is that Linux distributors cannot afford > supporting minor LSMs. > > Dave Chinner said > > Downstream distros support all sorts of out of tree filesystems loaded > via kernel modules > > at https://lkml.kernel.org/r/ZQo94mCzV7hOrVkh@xxxxxxxxxxxxxxxxxxx , and e.g. > antivirus software vendors use out of tree filesystems loaded via kernel > modules (because neither the upstream kernel community nor the Linux distributors > can afford supporting out of tree filesystems used by antivirus software vendors). > > If Linux distributors decide "we don't allow loading out of tree filesystems > via kernel modules because we can't support", that's the end of the world for > such filesystems. > > What I'm saying is nothing but s/filesystem/LSM/g . > If Linux distributors decide "we don't allow loading out of tree LSMs > via kernel modules because we can't support", that's the end of the world for > LKM-based LSMs. > > The mechanism which makes LKM-based LSMs possible must not be disabled by > the person/organization who builds the vmlinux. > > You might still say that "You can build your vmlinux and distribute it", but > that is also impossible in practice. Some device drivers are meant to be loaded > for Linux distribution's prebuilt kernels. Also, debuginfo package is needed for > analyzing vmcore. Building vmlinux and distributing it is not practical without > becoming a well-known Linux distributors enough to get out-of-tree device drivers > being prebuilt (such as Red Hat). > > Again, you are so blind. > > > Now, this patch and the patch that makes security_hook_heads > > __ro_after_init by removing CONFIG_SECURITY_HOOKS_WRITABLE breaks your > > hack. > > Like I demonstrated at https://lkml.kernel.org/r/cc8e16bb-5083-01da-4a77-d251a76dc8ff@xxxxxxxxxxxxxxxxxxx , > removing CONFIG_SECURITY_HOOKS_WRITABLE does not break my hack. >
