Hi author here. Are you saying it doesn't allow a malicious/compromised container to reduce the pool size down to something which might cause other daemons to block, possibly indefinitely, which need "strong" entropy vs using /dev/urandom? Sure it's a really silly DoS, but it might matter in the right situations.
I assume the original author meant to say: draining /dev/random does not affect the cryptographic quality of the random numbers produced by both devices.
But yes, since there's only one entropy pool, attackers can drain /dev/random, causing other programs that rely on /dev/random to block.
All I can say is: on newer kernels, attackers can still drain the pool by using the getrandom syscall, so unless you block that syscall, not mounting /dev/random does not increase the security.
"Draining" is a fantasy, statistics about it are manufactured by the kernel randomness subsystems. Are you concerned with your ssh keys "running out" too?
I got schooled about this a few days ago. Here's the thread: https://news.ycombinator.com/item?id=11485832. The tl;dr is that basically you should just use /dev/urandom unless you're in very weird circumstances. Entropy doesn't "run out" in that sense.
oh yes I agree /dev/urandom is the way to go, but the original comment said that the paper's suggestion that a container could exhaust the pool on /dev/random was false and that's what I was curious about. I thought it was possible to exhaust /dev/random...
I think all of the ancestors where saying that you couldn't use containers to "reduce the entropy" (which probably is meant to be "cause CSPRNG state to be known") won't happen because /dev/random blocking is done by some arbitrary statistic that has dubious reasons for existing. True, you can cause /deb/random to block, but that doesn't result in anything bad happening. Unless you have bad software that does bad things when reads block.
