Hacker News Reader

Comment by tptacek | Hacker News Reader

Exposing /dev/random in containers does not put the system entropy pool at risk. That claim is repeated twice in the paper, and is false.

View on HN

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.

It will never stop being repeated, will it?

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

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

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-uran... or http://security.stackexchange.com/a/14293/37

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.

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.

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.

I may be wrong, but the container could drain the pool stopping applications like Tomcat from launching

Reply on news.ycombinator.com