Message-ID: <4E67C659.1080707@redhat.com>
Date:	Wed, 07 Sep 2011 15:30:33 -0400
From:	Jarod Wilson <jarod@...hat.com>
To:	Sasha Levin <levinsasha928@...il.com>
CC:	linux-crypto@...r.kernel.org, Matt Mackall <mpm@...enic.com>,
	Neil Horman <nhorman@...hat.com>,
	Herbert Xu <herbert.xu@...hat.com>,
	Steve Grubb <sgrubb@...hat.com>,
	Stephan Mueller <stephan.mueller@...ec.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] random: add blocking facility to urandom

Sasha Levin wrote:
> On Wed, 2011-09-07 at 14:26 -0400, Jarod Wilson wrote:
>> Sasha Levin wrote:
>>> On Wed, 2011-09-07 at 13:38 -0400, Jarod Wilson wrote:
>>>> Certain security-related certifications and their respective review
>>>> bodies have said that they find use of /dev/urandom for certain
>>>> functions, such as setting up ssh connections, is acceptable, but if and
>>>> only if /dev/urandom can block after a certain threshold of bytes have
>>>> been read from it with the entropy pool exhausted. Initially, we were
>>>> investigating increasing entropy pool contributions, so that we could
>>>> simply use /dev/random, but since that hasn't (yet) panned out, and
>>>> upwards of five minutes to establsh an ssh connection using an
>>>> entropy-starved /dev/random is unacceptable, we started looking at the
>>>> blocking urandom approach.
>>> Can't you accomplish this in userspace by trying to read as much as you
>>> can out of /dev/random without blocking, then reading out
>>> of /dev/urandom the minimum between allowed threshold and remaining
>>> bytes, and then blocking on /dev/random?
>>>
>>> For example, lets say you need 100 bytes of randomness, and your
>>> threshold is 30 bytes. You try reading out of /dev/random and get 50
>>> bytes, at that point you'll read another 30 (=threshold) bytes
>>> out /dev/urandom and then you'll need to block on /dev/random until you
>>> get the remaining 20 bytes.
>> We're looking for a generic solution here that doesn't require
>> re-educating every single piece of userspace. [...]
>
> A flip-side here is that you're going to break every piece of userspace
> which assumed (correctly) that /dev/urandom never blocks.

Out of the box, that continues to be the case. This just adds a knob so 
that it *can* block at a desired threshold.

> Since this is
> a sysctl you can't fine tune which processes/threads/file-handles will
> block on /dev/urandom and which ones won't.

The security requirement is that everything blocks.

>> [..] And anything done in
>> userspace is going to be full of possible holes [..]
>
> Such as? Is there an example of a case which can't be handled in
> userspace?

How do you mandate preventing reads from urandom when there isn't 
sufficient entropy? You likely wind up needing to restrict access to the 
actual urandom via permissions and selinux policy or similar, and then 
run a daemon or something that provides a pseudo-urandom that brokers 
access to the real urandom. Get the permissions or policy wrong, and 
havoc ensues. An issue with the initscript or udev rule to hide the real 
urandom, and things can fall down. Its a whole lot more fragile than 
this approach, and a lot more involved in setting it up.

>>   [..] there needs to be
>> something in place that actually *enforces* the policy, and centralized
>> accounting/tracking, lest you wind up with multiple processes racing to
>> grab the entropy.
>
> Does the weak entropy you get out of /dev/urandom get weaker the more
> you pull out of it? I assumed that this change is done because you want
> to limit the amount of weak entropy mixed in with strong entropy.

The argument is that once there's no entropy left, an attacker only 
needs X number of samples before they can start accurately determining 
what the next random number will be.

> btw, Is the threshold based on a research done on the linux RNG? Or is
> it an arbitrary number that would be set by your local sysadmin?

Stephan (cc'd on the thread) is attempting to get some feedback from BSI 
as to what they have in the way of an actual number. The implementation 
has a goal of being flexible enough for whatever a given certification 
or security requirement says that number is.

-- 
Jarod Wilson
jarod@...hat.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists