Date: Tue, 28 Nov 2017 16:17:05 -0800 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Geo Kozey <geokozey@...lfence.com> Cc: LSM List <linux-security-module@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules On Tue, Nov 28, 2017 at 3:51 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote: > > So a patch that avoids breaking existing users, but also doesn't > actually improve anything for existing users, simply shouldn't be part > of the mainline kernel. Just to clarify: maybe it ends up being truly impossible to make the default be more restrictive. The default certainly won't be the most restrictive option. But at the same time, if people can't even be bothered to try to improve the general case, and only do things that you have to opt in for, it really isn't much of an improvement. We had this whole "opt-in" discussion for another thread entirely, and it basically didn't improve anything for anybody for the better half of a decade. Hardening that only works for special cases isn't hardening at all. It will just mean that 99+% of all kernel developers won't see the fallout at all. Yes, something like Android may be 99% of the devices, but it's a very small portion of the core developer base because the hardware is all locked down, and it's an even smaller portion of the usage patterns. So I can see some people say "We can use this for android and protect the 99%". But if it then is basically invisible to the rest of the user base, it means that all those servers etc aren't getting the kind of protection they should have. Just to take that DCCP thing as an example: being a module wasn't what made it vulnerable. It would have been vulnerable compiled in too. What made it vulnerable was that the DCCP code simply isn't widely enough used and tested, and basically barely on life support. And it was available much too widely despite that. So all this is about is to make for a smaller attack surface. But if it turns out that we can make the attack surface smaller by simply white-listing a few modules that we know are actively used and feel better about the quality of, that makes for a much smaller attack surface _too_. And it does so in general, without having to set some flag that 99% of all MIS people won't even really know about. So that's why I want people to look at a different approach. Yes, the opt-in model means that by default nothing changes. That protects against the whole "oops, we don't break user space". But it has a huge downside. The model that I am a proponent of is to take a softer approach initially: don't forbid module loading (because that breaks users), but instead _warn_ about non-root module loading. And then we can start fixing the cases that we find. See? This is *exactly* the same thing that the user-mode access thing was about. Hardening people need to get over their "hard rules" mindset. We don't kill processes or forbid them from doing things that might be bad. We start by warning about them, to see what "might be bad" cases are actually normal, and not actually bad at all. And then we use that information to guide our notion of what should actually trigger a stronger response. Linus
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.