kernel-hardening - Re: [PATCH v4] scripts: add leaking

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 8 Nov 2017 07:58:20 +1100
From: "Tobin C. Harding" <me@...in.cc>
To: David Laight <David.Laight@...LAB.COM>
Cc: "kernel-hardening@...ts.openwall.com"
 <kernel-hardening@...ts.openwall.com>,
	"Jason A. Donenfeld" <Jason@...c4.com>,	Theodore Ts'o <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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@...r.kernel.org" <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 07, 2017 at 01:56:05PM +0000, David Laight wrote:
> From: Tobin C. Harding
> > Sent: 07 November 2017 10:32
> >
> > Currently we are leaking addresses from the kernel to user space. This
> > script is an attempt to find some of those leakages. Script parses
> > `dmesg` output and /proc and /sys files for hex strings that look like
> > kernel addresses.
> ...
> 
> Maybe the %p that end up in dmesg (via the kernel message buffer) should
> be converted to text in a form that allows the code that reads them to
> substitute alternate text for non-root users?
>
> Then the actual addresses will be available to root (who can probably
> get most by other means) but not to the casual observer.

Interesting idea. Isn't the same outcome already achieved with
dmesg_restrict. I appreciate that this does beg the question 'why are we
scanning dmesg then?'

There has not been much discussion on dmesg_restrict. Is dmesg_restrict
good enough that we needn't bother scanning it?

thanks for your input,
Tobin.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.