On Wed, Sep 07, 2011 at 04:02:24PM -0400, Steve Grubb wrote: > On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote: > > On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote: > > > We're looking for a generic solution here that doesn't require > > > re-educating every single piece of userspace. And anything done in > > > userspace is going to be full of possible holes -- 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. > > > > Yeah, but there are userspace programs that depend on urandom not > > blocking... so your proposed change would break them. > > The only time this kicks in is when a system is under attack. If you have set this and > the system is running as normal, you will never notice it even there. Almost all uses > of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses those > libraries. There are the odd cases where something uses urandom to generate a key or > otherwise grab a chunk of bytes, but these are still small reads in the scheme of Theres no way you can guarantee that. A quick lsof on my system here shows 27 unique pids that are holding /dev/urandom open, and while they may all be small reads, taken in aggregate, I can imagine that they could pull a significant amount of entropy out of /dev/urandom. > things. Can you think of any legitimate use of urandom that grabs 100K or 1M from > urandom? Even those numbers still won't hit the sysctl on a normally function system. > How can you be sure of that? This seems to make assumptions about both the rate at which entropy is drained from /dev/urandom and the limit at which you will start blocking, neither of which you can be sure of. > When a system is underattack, do you really want to be using a PRNG for anything like How can you be sure that this only happens when a system is under some sort of attack. /dev/urandom is there for user space to use, and we can't make assumptions as to how it will get drawn from. What if someone was running some monte-carlo based test program? That could completely exhaust the entropy in /dev/urandom and would be perfectly legitimate. > seeding openssl? Because a PRNG is what urandom degrades into when its attacked. If > enough bytes are read that an attacker can guess the internal state of the RNG, do you > really want it seeding a openssh session? At that point you really need it to stop > momentarily until it gets fresh entropy so the internal state is unknown. That's what > this is really about. I never really want my ssh session to be be seeded with non-random data. Of course, in my mind thats an argument for making ssh use /dev/random rather than /dev/urandom, but I'm willing to take the tradeoff in speed most of the time. > > -Steve -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
