[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
