4 ms·

Could you link to supporting reference? Is there some smarts in the kernel to namespace, block or limit draining?

throwaway2048 10y ago
"Draining" is a fantasy, statistics about it are manufactured by the kernel randomness subsystems. Are you concerned with your ssh keys "running out" too?
- raesene6 10y ago
  excuse my potential ignorance, but I thought that /dev/random was at risk of exhaustion in the general case, with /dev/urandom not being so... e.g. http://www.onkarjoshi.com/blog/191/device-dev-random-vs-urandom/ http://www.onkarjoshi.com/blog/191/device-dev-random-vs-uran... or http://security.stackexchange.com/a/14293/37 http://security.stackexchange.com/a/14293/37
  - cyphar 10y ago
    I got schooled about this a few days ago. Here's the thread: https://news.ycombinator.com/item?id=11485832 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.
    - raesene6 10y ago
      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...
      - cyphar 10y ago
        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.
zuzun 10y ago
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.
- dyn 10y ago
  Hi author here. Yes, that is what I was trying to say. I'll clarify it in a future version. That's a good point, I'll include that! Thanks.

throwaway2048 10y ago

"Draining" is a fantasy, statistics about it are manufactured by the kernel randomness subsystems. Are you concerned with your ssh keys "running out" too?

raesene6 10y ago
excuse my potential ignorance, but I thought that /dev/random was at risk of exhaustion in the general case, with /dev/urandom not being so... e.g. http://www.onkarjoshi.com/blog/191/device-dev-random-vs-urandom/ http://www.onkarjoshi.com/blog/191/device-dev-random-vs-uran... or http://security.stackexchange.com/a/14293/37 http://security.stackexchange.com/a/14293/37
- cyphar 10y ago
  I got schooled about this a few days ago. Here's the thread: https://news.ycombinator.com/item?id=11485832 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.
  - raesene6 10y ago
    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...
    - cyphar 10y ago
      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.

zuzun 10y ago

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.

dyn 10y ago
Hi author here. Yes, that is what I was trying to say. I'll clarify it in a future version. That's a good point, I'll include that! Thanks.