On 9/15/2022 7:27 AM, Tetsuo Handa wrote: > On 2022/09/14 22:56, Paul Moore wrote: >> On Fri, Sep 9, 2022 at 7:33 AM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: >>> Inclusion into upstream is far from the goal. >> For better or worse, there is a long history of the upstream Linux >> Kernel focusing only on in-tree kernel code, I see no reason why we >> should change that now for LSMs. > Because we can't afford accepting/maintaining whatever LSMs that are proposed. We've done a reasonable job so far. Part of the process of getting a security module upstream is demonstrating that it will (1) add value, (2) get used and (3) continue to be maintained. Several modules have been proposed that looked like they would add value and get used, but that the author(s) had no means to maintain. > Do you think that we are going to accept/maintain whatever LSMs that are proposed > if we get to the point to "The commitment I made to Paul some years ago now was > that the stacking would eventually include making all combinations possible" ? > I don't think so. Neither do I. What I want to do is break down the existing technical barrier. If Redhat wants to continue with their "SELinux only" position, that's their call. If Ubuntu wants to take a more inclusive approach they should be able to. That does not mean that every bizarre and/or unnatural security module that's proposed should be included in the mainline. > Although the upstream Linux Kernel focuses only on in-tree kernel code, > CONFIG_MODULES=y is not limited for in-tree kernel code. It is used by e.g. > device vendors to deliver their out-of-tree driver code. I see this argument all the time. The response is "get your driver upstream". Vendors/developers who whine "It's too hard" get no sympathy from me. > Then, I see no reason > why we can't do the same for LSMs. We simply don't need to "provide efforts for > fixing bugs in whatever LSMs"; we simply should "allow whatever LSMs to exist". >
