[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 4 Oct 2017 10:08:02 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <keescook@...omium.org>
Cc: "Tobin C. Harding" <me@...in.cc>, 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>, LKML <linux-kernel@...r.kernel.org>,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>,
Steven Rostedt <rostedt@...dmis.org>, William Roberts <william.c.roberts@...el.com>,
Chris Fries <cfries@...gle.com>, Dave Weinstein <olorin@...gle.com>
Subject: Re: [RFC V2 4/6] lib: vsprintf: default
kptr_restrict to the maximum value
On Wed, Oct 4, 2017 at 9:42 AM, Kees Cook <keescook@...omium.org> wrote:
>
> I'd argue that a default of "1" would be a sensible starting place,
> but that can be a separate patch, IMO.
I agree that '1' is a much saner default for _some_ uses, in that it
still gives root access to /proc file data etc.
However, the sad fact is that kptr_restrict just has bad semantics for
that case too, in that you do want to give root access to /proc files,
but the whole "is the current thread root" is a horrible horrible
test.
Partly it's horrible for the reasons mentioned in the source code (ie
the whole IRQ context thing etc), but that's actually the smallest
reason it's not great: the more fundamental issue is that even for
/proc files, it should use the cred for the file opener, not the
current user.
And for anything *but* /proc files, it's almost always the wrong thing
(ie random printk's aren't generally really associated with any user).
It might almost by mistake do the right thing (ie some kernel printk
that can be triggered by a normal user doing something odd), so it's
not like it always does the wrong thing, but it really is almost
entirely random.
So I seriously dislike kptr_restrict. The whole thing is mis-designed
for very very fundamental reasons.
And no, I also refuse to believe that the fix is "just make it have a
value of 4, and just hide all pointers". Because that will just mean
that people won't be using '%p' at all for debug messages etc, they'll
just use %x or whatever.
So I honestly doubt the value of kptr_restrict. Any *sane* policy
pretty much has to be in the caller, and by thinking about what you
print out. IOW, things like proc_pid_wchan().
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.
