Date: Fri, 13 Oct 2017 13:47:07 -0700 From: Kees Cook <keescook@...omium.org> To: Linus Torvalds <torvalds@...ux-foundation.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 1:22 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote: > 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? I totally agree that %pK isn't actually useful. (I think of %pK and a global flag controlling %p behavior as separate things.) The original patch I was talking about fully acknowledges this (%pK not actually working) and was about changing %p behavior. Some other solution was needed that didn't drive developers into using %x for everything instead. > 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. So yes, it's trivial to scan for stuff in dmesg, but it's much less trivial to find the cases where some /proc entry only has %p reports under certain runtime conditions. (e.g. print the allocation address of a pending wifi association timer or something: visible only during a brief window, and something not obvious to a casual scan of /proc entry contents, but an attacker might be able to influence and peek at.) I'm also fine with eliminating the use of %p in source, but that's a serious game of whack-a-mole, and I don't think it scales. So, yeah, while I do like the %p-hash idea, I remain concerned that we'll just have this whole discussion again in a few years, trying to figure out what to do about the now heavily-used %x. Is the correct path to: - unconditionally convert %p to reporting a 32-bit hash - actively start removing as much %p use as possible - do something to discourage %x on pointers (checkpatch.pl?) Can we do something more about %x? Do we want to remove %pK also? -Kees -- Kees Cook Pixel Security
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.