Message-ID: <CA+55aFykjza0H5ytZH_aJKYs9tC84OLyVT30--cvo0mpAzpWaA@mail.gmail.com>
Date:   Fri, 17 Nov 2017 13:13:10 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     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

On Fri, Nov 17, 2017 at 12:35 PM, Kees Cook <keescook@...omium.org> wrote:
>
> This is why I introduced the fallback mode: with both kvm and sctp
> (ipv6) not noticed until late in the development cycle, I became much
> less satisfied it had gotten sufficient testing.

So honestly, this is the kind of completely unacceptable "security
person" behavior that we had with the original user access hardening
too, and made that much more painful than it ever should have been.

IT IS NOT ACCEPTABLE when security people set magical new rules, and
then make the kernel panic when those new rules are violated.

That is pure and utter bullshit. We've had more than a quarter century
_without_ those rules, you don't then suddenly walz in and say "oh,
everbody must do this, and if you haven't, we will kill the kernel".

The fact that you "introduced the fallback mode" late in that series
just shows HOW INCREDIBLY BROKEN the series started out.

Seriously.

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.

The important part about "just bugs" is that you need to understand
that the patches you then introduce for things like hardening are
primarly for DEBUGGING.

I'm not at all interested in killing processes. The only process I'm
interested in is the _development_ process, where we find bugs and fix
them.

As long as you see your hardening efforts primarily as a "let me kill
the machine/process on bad behavior", I will stop taking those shit
patches.

I'm deadly serious about this.

Some security people have scoffed at me when I say that security
problems are primarily "just bugs".

Those security people are f*cking morons.

Because honestly, the kind of security person who doesn't accept that
security problems are primarily just bugs, I don't want to work with.
If you don't see your job as "debugging first", I'm simply not
interested.

So I think the hardening project needs to really take a good look at
itself in the mirror.

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".

And the primary focus right now seems to be "let's kill things for
bugs". That's wrong.

And I'm _so_ not interested in that. It makes me go "no, I will not
pull that shit, it's not safe for me, and it's not safe for our
users".

So the hardening efforts should instead _start_ from the standpoint of
"let's warn about what looks dangerous, and maybe in a _year_ when
we've warned for a long time, and we are confident that we've actually
caught all the normal cases, _then_ we can start taking more drastic
measures".

See the difference?

Stop this idiotic "kill on sight, ask questions later".

Because it's wrong.

> I would agree it would be nice to get at least a subset of this in,
> though. Linus, what would make you most comfortable?

Right now, the biggest problem for me is that the whole thing makes me
uncomfortable, because I think the people involved are coming from a
completely unacceptable model to begin with.

And we had this exact issue with the _previous_ user mode access
hardening. People apparently didn't learn a goddamn thing.

                     Linus

Powered by blists - more mailing lists