Date: Tue, 7 Nov 2017 16:59:56 -0800 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Laura Abbott <labbott@...hat.com> Cc: "Tobin C. Harding" <me@...in.cc>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, "Jason A. Donenfeld" <Jason@...c4.com>, "Theodore Ts'o" <tytso@....edu>, Kees Cook <keescook@...omium.org>, Paolo Bonzini <pbonzini@...hat.com>, Tycho Andersen <tycho@...ker.com>, "Roberts, William C" <william.c.roberts@...el.com>, 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>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <wilal.deacon@....com>, Steven Rostedt <rostedt@...dmis.org>, Chris Fries <cfries@...gle.com>, Dave Weinstein <olorin@...gle.com>, Daniel Micay <danielmicay@...il.com>, Djalal Harouni <tixxdz@...il.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Network Development <netdev@...r.kernel.org>, David Miller <davem@...emloft.net> Subject: Re: [PATCH v4] scripts: add leaking_addresses.pl On Tue, Nov 7, 2017 at 3:36 PM, Laura Abbott <labbott@...hat.com> wrote: > > I'd probably put /proc/kallsyms and /proc/modules on the omit list > since those are designed to leak addresses to userspace. Well, they are indeed designed to leak addresses, but not a lot of people should care. So I think we could tighten them up. For example, maybe /proc/kallsyms could just default to not showing values to non-root users. We *did* originally try to use "kptr_restrict" with a default value of 1, it's just that it was never fixable on a case-by-case basis as people started saying "that breaks my flow, because xyz". But if we do it for one file at a time, we probably *can* try to fix complaints. Something like the attached TOTALLY UNTESTED patch. It's meant more as an RFC, not for application, but it's also meant to show how we can tailor the behavior for specific workflow issues. So take that "kallsyms_for_perf()" thing as an example of how we can say "hey, if you already have access to kernel profiling anyway, there's no point in hiding kallsyms". And there may be other similar things we can do. The situation with /proc/modules should be similar. Using kptr_restrict was a big hammer and might have broken something unrelated, but did anybody actually care about the particular case of /proc/modules not showing the module address to normal users? probably not. "lsmod" certainly doesn't care, and that's what people really want. Both /proc/kallsyms and /proc/modules _used_ to be really important for oops reporting, but that was long ago when the kernel didn't report symbol information of its own. So we have historical reasons for people to be able to read those files, but those are mainly things that aren't relevant (or even possible) on modern kernels anyway. So I don'r think we should omit /proc/kallsyms and /proc/modules - we should just fix them. The attached patch may not be good enough as is, but maybe something _like_ it will work well enough that people won't care? (And do note the "TOTALLY UNTESTED". It seems to compile. But maybe I got some test exactly the wrong way around and it doesn't actually _work_. Caveat testor). Linus View attachment "patch.diff" of type "text/plain" (2543 bytes)
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.