Messages in this thread | | | From | "Jason A. Donenfeld" <> | Date | Tue, 21 Nov 2017 14:48:40 +0100 | Subject | Re: [GIT PULL] usercopy whitelisting for v4.15-rc1 |
| |
Hi Linus,
On Fri, Nov 17, 2017 at 10:13 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > As a security person, you need to repeat this mantra: > > "security problems are just bugs" > > and you need to _internalize_ it, instead of scoff at it.
It might be news to you that actually some security people scoff at other security peoples' obsession with "security bugs".
Security people like to rate the "utility" of a bug in a security setting, usually from from "does nothing" (benign) to "allows code execution" (dangerous/useful), with something like "crashes system" somewhere in between those two poles. (You may not agree with this scale, but indeed security people tend to think that a crash is safer than allowing malicious code execution.)
The security industry is largely obsessed by finding (and selling/using/patching/reporting/showcasing/stockpiling/detecting/stealing) these "dangerous/useful" variety of bugs. And this obsession is continually fulfilled because bugs keep happening -- which is just the nature of software development -- and so this "security bug" infatuation continues. It even leads to people upset with you that you don't care about CVEs and so forth, because they're so fixated on individual bugs and their security impact.
So, as I mentioned, it may come as a surprise to you that some security people don't really care for that mentality. As Bas Alberts wrote [1], "Bugs are irrelevant. Yet our industry is fatally focused on what is essentially vulnerability masturbation." So what's the alternative to obsessing over each individual software bug?
In the context of the kernel, the solution from Spender and Pipacs, and more recently "adopted" by Kees and his KSPP project, has been to try to eliminate the "security utility" of bugs. In the best case, this means making bugs that were formerly "dangerous/useful" be "benign". In the second best case, it usually means making bugs that were formerly "dangerous/useful" be "irreliable" or "crashes system". The idea is to completely eliminate the security impact of entire *classes* of bugs. It acknowledges that programmers will continue to make programming bugs, as they do, and seeks to make the kernel safer, from a security perspective, in spite of the continued existence of these bugs.
> Because the primary focus should be "debugging". The primary focus > should be "let's make sure the kernel released in a year is better > than the one released today".
In light of the above, this then is where there might be an unfortunate disconnect. Sure, many hardening features that turn dangerous bugs into less dangerous bugs have the quality of unearthing individual bugs. But many other aspects are rightfully focused on mitigating the security impact future unforeseen, undetected bugs. From a security perspective, please try to see beyond the individual bug obsession, and consider the larger picture. After all, if the security impact of all kernel bugs is reduced to nil, your mantra that all bugs are just bugs will be even more true.
Jason
[1] https://lists.immunityinc.com/pipermail/dailydave/2015-August/000976.html
| |