[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxZo5kZEiZFYj5mns3Tsgb0JLC_rae2ThObeM5xrC8Mug@mail.gmail.com>
Date: Fri, 13 Oct 2017 13:22:56 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <keescook@...omium.org>
Cc: "Roberts, William C" <william.c.roberts@...el.com>, "Theodore Ts'o" <tytso@....edu>,
"Tobin C. Harding" <me@...in.cc>, Tejun Heo <tj@...nel.org>,
Jordan Glover <Golden_Miller83@...tonmail.ch>, Greg KH <gregkh@...uxfoundation.org>,
Petr Mladek <pmladek@...e.com>, Joe Perches <joe@...ches.com>, Ian Campbell <ijc@...lion.org.uk>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>,
Steven Rostedt <rostedt@...dmis.org>, Chris Fries <cfries@...gle.com>,
Dave Weinstein <olorin@...gle.com>
Subject: Re: [RFC V2 0/6] add more kernel pointer filter options
On Fri, Oct 13, 2017 at 12:34 PM, Kees Cook <keescook@...omium.org> wrote:
> On Fri, Oct 13, 2017 at 11:11 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>> And even as a "failure", the global flag may well work fine for soem
>> uses (ie Android), largely because hardly anybody actually _develops_
>> using Android. So it may not have been a failure in that sense, and
>> for all I know the Android use-case really sees it as a huge success
>> (and extending on it there would have made sense).
>
> That's precisely where this comes from: the original patches from
> Tobin (and Greg) were trying to make this extension, based on the work
> done in the Android kernels (which was based on work by William, etc).
Yes, but what I want so-called "security" people and Andoid people to
acknowledge is that it was
(a) a hack
(b) not actually real security
(c) didn't actually help long-term development at all, and in fact
likely held real improvements *back* because it was "whatever, we
don't have a problem".
It's security theater. Particularly with the opt-in, it was never
anything more. There are _very_ few %pK users in the kernel, and those
that are there could generally have been just removed entirely, or
have been made to check the flag _locally_ instead of globally, and
been made better in the process.
The new extension that raised kptr_restrict to 4 was just more of the
same. It was in no way real security. It's exactly the same as the TSA
"advisory system" color coding.
Do you seriously believe that color coded threat levels were a good
thing? The whole "kptr_restrict=4" is exactly the same thing as the
TSA "threat level red". It's a joke. It doesn't actually _fix_
anything.
Guys, it took me five seconds to come up with that
dmesg | egrep '[0-9a-f]{16}'
pattern, and find several printouts that weren't %pK, and that
wouldn't have been caught by the new "strict" color coding EITHER.
Seriously. It's BS.
It's BS exactly the same way profiling by the TSA is BS. Sure, if you
stop "brown single male" passengers, you probably will stop
something. But you don't really _fix_ anything.
The "%p" pattern is just the kernel equivalent of "brown single male".
It's not a real security fix, it never has been, and it never will be.
There are probably _more_ places that export physical addresses with
%x than with %pa.
So what I suggested was that we actually look at what the kernel
exports, and we make it easy to just shut _real_ problems down.
The whole "let's make %p print a hashed address" is not the real
security part. That's just the "make it easy to do something secure by
_default_" part. The real security is actually scanning for bad
things, not profiling the escape sequences.
Is "scan for potential actual; leaks" some kind of absolute security?
No. But at least it's not just silly games.
>> Hopefully just making %p print out a hash will fix the silly things.
>
> I'm unable to tell if you're universally opposed to a global flag, or
> if you're acknowledging that it has use in certain environments.
I'm acknowledging that it's a complete hack that may have made sense
in a particular setting, but it's not one that actually fixes any real
security issues, and in particular, it's one that has likely held
people back from doing *real* security.
And as a maintainer of the kernel, to me that "long term actual
development" is a whole lot more important than "silly hack that might
close a random escape or two".
So yes, I'm actually opposed to the global flag, because we seriously
have 6+ years of reality staring us in the face: it fixed exactly
nothing. It fixed /proc/kallsyms,m but did so _badly_. It fixed a
handful of other places. But it didn't really and truly add any real
security.
Are people really in denial about this? Really?
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.
