Re: [Security] [PATCH] proc: avoid information leaks to non-privileged processes

From: Ingo Molnar <mingo@elte.hu>
To: Matt Mackall <mpm@selenic.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Arjan van de Ven <arjan@infradead.org>, Jake Edge <jake@lwn.net>,
	security@kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	James Morris <jmorris@namei.org>,
	linux-security-module@vger.kernel.org,
	Eric Paris <eparis@redhat.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Roland McGrath <roland@redhat.com>,
	mingo@redhat.com, Andrew Morton <akpm@linux-foundation.org>,
	Greg KH <greg@kroah.com>, Dave Jones <davej@redhat.com>
Subject: Re: [Security] [PATCH] proc: avoid information leaks to non-privileged processes
Date: Tue, 5 May 2009 08:31:56 +0200	[thread overview]
Message-ID: <20090505063156.GA24504@elte.hu> (raw)
In-Reply-To: <20090505055011.GE31071@waste.org>

* Matt Mackall <mpm@selenic.com> wrote:

> As to what's the appropriate sort of RNG for ASLR to use, finding 
> a balance between too strong and too weak is tricky. [...]

In exec-shield i mixed 'easily accessible and fast' semi-random 
state to the get_random_int() result: xor-ed the cycle counter, the 
pid and a kernel address to it. That strengthened the result in a 
pretty practical way (without strengthening the theoretical 
randomless - each of those items are considered guessable) and does 
so without weakening the entropy of the random pool.

As usual, it got objected to and removed during upstream review so 
the upstream code stands on a single foot only - which is an 
obviously bad idea.

The thing is, it's very hard to argue for (and prove) security 
related complexity on an objective basis. ASLR was met with quite 
some upstream hostility, so it did not really get merged upstream, 
it barely managed to limp upstream.

	Ingo