Message-ID: <CAHmME9qPMc21-ZzgKUdS8ZfUcJ=QDmYkRCgbzTuJBvpJ1TX3TQ@mail.gmail.com>
Date:   Tue, 21 Nov 2017 14:48:40 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        David Windsor <dave@...lcore.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

Hi Linus,

On Fri, Nov 17, 2017 at 10:13 PM, Linus Torvalds
<torvalds@...ux-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

Powered by blists - more mailing lists