/dev/random and /dev/urandom have security attributes: ownership and permission. The newly proposed syscall makes no security checks whatsoever to protect the entropy resource: it punches a hole through these perms, effectively.
I think the concern is that a process could then exhaust all available entropy, and DOS any other processes depending on /dev/random. Currently, a chroot could protect against that.
A security case for protecting a source of random bits is that they are important and that cryptographic applications and middleware can malfunction if these bits are not available. A world-readable /dev/random means that anyone can drain out random bits, making them unavailable to these applications.
Someone somewhere could be setting up permissions in their Linux-based system based on this type of reasoning.
It's a security regression if a character device can be suddenly accessed through a back-channel that ignores permissions.
If you don't trust a CSPRNG, then you pretty much might as well turn off all your crypto because you can't trust it.
If you can trust a CSPRNG, then you should be able to trust urandom, as long as it's been properly initialized once. It won't drain out. It doesn't run out of bits. One application reading it doesn't make it unavailable for others. The same is true of the syscall.
Short version is, on Solaris, you should use /dev/random for long-term keys and other high-value keying material. /dev/urandom should be used for everything else such as less demanding or shorter-term cryptographic uses like short-term session keys, paddings, and challenge strings.
1. It's not safe to use a weak RNG for session keys or even padding. Cryptosystems often fail catastrophically when their most obscure parameters are weak --- in fact, more exploitable cryptosystem flaws derive from issues like padding and IVs than keys.
2. FIPS 186-2 is a SHA-based DRBG. It doesn't "run out of entropy". What am I missing? The situation on Solaris w/r/t urandom appears to be identical to that of Linux.
1. The Solaris crypto designers / developers believe their rng is is appropriate for short-term session keys and padding. Read the post I linked before as to why the believe that.
2. /dev/random basically only uses bits from entropy sources while /dev/urandom just uses a few bits from /dev/random as a seed. Read the post I linked again.
Again, I would reiterate, the situation is somewhat different for Solaris. Usage of /dev/random vs. /dev/urandom is actually considered different.
I read this post, both when you linked to it just now, and, prior to that, while I was researching the urandom blog post I wrote a few months ago. I'm being repetitive, but:
* I think the distinction this post is drawing between Solaris random and urandom is functionally very similar to the distinction between Linux random and urandom (I think the distinction on Solaris might be that random has a higher quality rekeying system than urandom).
* I can read a straightforward description of a SHA1 PRNG keyed by kernel entropy, which is what this blog post describes, and unless I'm missing something in the article, I don't see how it is any less cryptographically secure than Solaris /dev/random. It seems to be less forward-secure than /dev/random. That's about it.
Since you appear to have grokked this article better than I did in either of the two cases I read it, could you give a short summary of the argument it presents for avoiding urandom for long-term secrets?
1) You're not completely off here; the primary difference is currently higher quality re-keying for /dev/random, but there are implementation differences.
2) From a cryptography standpoint, the precise implementation of the current framework makes /dev/urandom suitable for short-term session keys and padding. This may not hold true for Linux, but for Solaris it has been reviewed and deemed appropriate usage. Fundamentally, it's about constraints placed on the implementation that currently make /dev/random more "secure".
In conversing with one of the crypto developers for Solaris, they are considering whether to lessen the distinction between /dev/random and /dev/urandom further in the future.
/dev/random and /dev/urandom have security attributes: ownership and permission. The newly proposed syscall makes no security checks whatsoever to protect the entropy resource: it punches a hole through these perms, effectively.