Re: [dsfjdssdfsd] getentropy(2)

[Theodore Ts'o <[e-mail]>]

On Mon, Jul 14, 2014 at 07:54:33PM -0700, Watson Ladd wrote:
> Dear all,
> 
> The absence of getentropy(2) on Linux is a major pain point for
> everyone. It turns out that chroot jails are not compatible with
> /dev/urandom. which doesn't work on linux anyway (because it will
> return junk before initialization). As a TLS developer myself
> (slowly!) I feel that pain: random number generation is the single
> nastiest problem I have to deal with.

I've been talking to Bob Beck about this; and I'm not really convinced
how important the presense or lack of getneoptry(2) really is.  A
couple of high points about our conversation:

1) The question of what to do if /dev is not properly set up is a bit
of a red herring.  The OpenBSD folks have said that this is not a high
priority for them.  My perspective is that given that the ELF loader
requires that /dev/null be present so it can mmap in zero pages,
worrying about what to do if /dev is not properly set up is probably
not that big of a deal, and aborting if /dev/[u]random is not present is
probably the right thing to do.

2) OpenBSD's primary concern is to protect against the case when the
attacker has consumed all available file descriptors, so the attempt
to open /dev/[u]random fails.  Whether this is something that
justifies a new system call is a bit of a philosophical question.
After all, if the system is under such an attack, it's likely that
many other things will fail, and so failing hard may be better than
failing in a soft fashion.  There may be other portions of the system
that aren't properly checking for these sorts of failure.  For
example, are applications or libraries that try opening files such as
/etc/hosts.deny, if they receive an error, are they distinguishing
between ENOENT and EMFILE or ENFILE?  Or are the applications just
saying, "gee, open("/etc/hosts.deny", O_RDONLY) returned -1, all is
good, let's proceed"?

So points (1) and (2) means that from a philosophical point of view,
you can certainly make the argument that it's actually better to try
opening /dev/[u]random, and if it fails for any reason, it's better to
hard fail the application with a LOG_ERR or LOG_CRIT syslog followed
by an abort() call.

3) OpenBSD's man page for getentropy(2) talks about "seed grade"
entropy, but this is a bit of a misnomer for those people who are
obsessed about the difference between a DRBG and NRBG in SP 800-90A
speak.  Hence, getentropy(2) is non-blocking, and in practice, never
fails (or at least applications are written assuming that it
non-blocks and never fails).

I'm willing in practice to try seeing if I can get consensus for
adding a system call that works like getentropy(2).  I'm probably
going to add a flags field so that the application can select between
a blocking /dev/random read versus a non-blocking /dev/urandom read.
However, it's not clear that enough people will believe that adding a
system call just to justify allowing the userspace arc4random pool to
be able to initialize, only to have some other part of the application
fail due to a file open failing, or worse, silently compromising
security due to an open of some file such as /etc/hosts.deny failing,
is really worth adding a whole new system call.

> Yes, this is different from the usual IETF standard. But application
> and library developers need a portable way to get entropy, and that
> has to be the same across all platforms, work every time. Nothing
> short of a standard system call will work. Perhaps there is a more
> appropriate venue like the Open Group or POSIX or the Cxx committee
> (no doubt C++ will happily adopt it: a feature not in C++ is always a
> bug).

What I'd much rather see is a standard library that *all* applications
can rely upon and use to get entropy.  I don't trust most application
programmers to write a userspace library correctly.  One approach is
to simply advise all applications to use something like getentropy(2)
directly --- even if all that is needed is random padding or IV's.
The problem is that if you do this, for systems that are trying make
some kind of distinction between DRBG and NRBG, you can very quickly
exhaust the supply of hardware-derived entropy.

I accept that there is significant disagreement about whether such
differences should be made, but to the extent that Intel felt it was
necessary to add an RDSEED instruction as well as RDRAND, it's clear
that the difference is something that at least some people care about.
And I suspect it's unfair to say that the only people who care are the
crazies^H^H^H^H^H^H^H engineers who think that FIPS certification
makes any sense other than a purely commercial one (i.e., being able
to sell to the US Government).

But if we get all applications to use the same library, we can
abstract away not only differences in operating system but also
security policies vis-a-vis DRBG/NDRBG blocking/nonblocking.  So what
*I* would prefer is a library interface where the application declares
what it wants the random numbers for:

* Monte carlo simulations
* Padding
* IV
* Session key
* long-term key

etc.  The library can then decide whether or not the overall system
policy should force application to block when generating long-term
keys, ala gpg, or whether it should getting non-blocking entropy
directly from the kernel, or whether using a userspace DRBG which is
initialized from kernel-supplied entropy is the right answer.

Basically, I don't want to leave this choice up to the application
writer, since many application writers won't be competent to make this
choice, and having consistency across different applications which are
conform to the organization's designated security officer seems to be
something that at least some organizations would want.

Cheers,

						- Ted