Date: Wed, 4 Oct 2017 12:22:47 -0400 From: Boris Lukashev <blukashev@...pervictus.com> To: Linus Torvalds <torvalds@...ux-foundation.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>, Linux Kernel Mailing List <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 0/6] add more kernel pointer filter options On Wed, Oct 4, 2017 at 11:41 AM, Linus Torvalds <torvalds@...ux-foundation.org> wrote: > On Sat, Sep 30, 2017 at 5:06 PM, Tobin C. Harding <me@...in.cc> wrote: >> lib: vsprintf: default kptr_restrict to the maximum value > > So I'm not convinced about this one. > > It removes kernel pointers even for root, which is annoying for things > like perf. > The debugging and perf use cases seem well suited for using a boot-time parameter to disable the restriction such as to allow sysadmins to boot in a manner permitting them to see these values, while running in production without the (potential) leaks. > And the only physical pointers we should print out during boot etc are > things we *need*. > > So kptr_restrict is wrong for that, bercause either we potentially > need those values for debugging ("why does my kernel not boot"), or > they shouldn't be printed at all. > > And I think _that_ is the real issue. If there are places that leak, > we should look at those, rather than just say "kptr_restrict". When adding modules from outside the mainline tree (zfs, aufs, scst, etc), we would not be able to audit the source, and risk leaking sensitive pointers from those components if we dont filter them out this way or in a similar programmatic manner. There's also the issue of containers' access to kernel output, making the "root concern" somewhat more complicated. Large distributions are known to use code which hasn't, and in some cases never can, pass through the upstreaming process in your tree (ZFS being the primary case i'm thinking of for licensing reasons), and it would be a shame to leave their users with a reduced security posture for letting them utilize things which can't get mainlined. > > Linus Are there production-context requirements for exposing this information, or is the thought that this really only screws up "trying to fix or understand" the execution environment, with those being debugging/tuning functions not usually performed on critical systems in operation? If its the latter, then for long running systems with relevant 0days we're not yet privy to, restriction on the attackers ability to map physmem can raise the bar for attack complexity significantly, offering real-world benefit to defenders while mitigation is implemented to correct the underlying concern. We do a fair share of work in medical environments, where applying a kernel update may involve FDA approval or other acrobatics through flaming hoops (specifically for implanted med devices and their base stations), so defensive measures providing blanket coverage for a class of attacker activity (recon of memory layout in this case) are very welcome to those consumers. -- Boris Lukashev Systems Architect Semper Victus
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.