Re: [PATCH] random: add blocking facility to urandom

Jarod Wilson
2011-09-07T19:30:44Z

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@redhat.com