Re: /dev/urandom in chroot
On Tue, Oct 29, 2013 at 02:06:48PM -0400, Gabriel Guzman wrote:
On 10/29, Theo de Raadt wrote:
snip
The /dev/*random nodes are not specified in any standard, furthermore
once you get into chroot all bets are off (like you discovered).
This allows the program to work, but I'm wondering if there is a better
way to do this that doesn't involve removing the nodev setting from
/var.
Rewrite it so that it uses other ways to get randomness. The arc4random
API is exposed in various programming layers.
Would it be preferable to use a language function for getting pseudo
random bytes instead of relying on the device?
Yes. Definately.
Great, thanks for confirmation on that, I'll fix the program so I don't
need to make devices inside my cozy chroot and push the changes upstream.
FWIW, on Linux there is also a way to access kernel randomness without using
a device file:
int mib[3] = { CTL_KERN, KERN_RANDOM, RANDOM_UUID };
uint32_t uuid[4];
sysctl(mib, 3, uuid, (size_t){ sizeof uuid }, (void *)0, 0);
You can just feed this into a simple KDF construction using a
cryptographically strong hash function, or feed it into OpenSSL's PRNG.
Caveat emptor: add appropriate error checking so you know if and when this
fails. I've never seen it fail, but the API is undocumented because Linux
eschews sysctl in favor of /proc and /dev, and theoretically it could
disappear.
Unfortunately, on OS X and FreeBSD arc4random(3) reads from /dev/random.
What a shame. Somebody was asleep at the wheel.
The safest behavior is to arrange to acquire randomness resources at startup
before chroot'ing, but obviously this is difficult to do in a self-contained
library.
/dev/urandom in chroot
Hello Misc, I have a web program that attempts to access /dev/urandom from within the /var/www chroot. Based on archive searches and googling, I've removed the nodev flag from that mount and have created the random devices in /var/www/dev/* This allows the program to work, but I'm wondering if there is a better way to do this that doesn't involve removing the nodev setting from /var. Would it be preferable to use a language function for getting pseudo random bytes instead of relying on the device? Thanks for your time, gabe.
Re: /dev/urandom in chroot
I have a web program that attempts to access /dev/urandom from within the /var/www chroot. Based on archive searches and googling, I've removed the nodev flag from that mount and have created the random devices in /var/www/dev/* So basically remove a layer of security. Awesome. See what they made you do? The /dev/*random nodes are not specified in any standard, furthermore once you get into chroot all bets are off (like you discovered). This allows the program to work, but I'm wondering if there is a better way to do this that doesn't involve removing the nodev setting from /var. Rewrite it so that it uses other ways to get randomness. The arc4random API is exposed in various programming layers. Would it be preferable to use a language function for getting pseudo random bytes instead of relying on the device? Yes. Definately.
Re: /dev/urandom in chroot
On 10/29, Theo de Raadt wrote: I have a web program that attempts to access /dev/urandom from within the /var/www chroot. Based on archive searches and googling, I've removed the nodev flag from that mount and have created the random devices in /var/www/dev/* So basically remove a layer of security. Awesome. See what they made you do? Yeah, I didn't feel like that was a great idea. I was fairly sure the nodev flag was put there on purpose. The /dev/*random nodes are not specified in any standard, furthermore once you get into chroot all bets are off (like you discovered). This allows the program to work, but I'm wondering if there is a better way to do this that doesn't involve removing the nodev setting from /var. Rewrite it so that it uses other ways to get randomness. The arc4random API is exposed in various programming layers. Would it be preferable to use a language function for getting pseudo random bytes instead of relying on the device? Yes. Definately. Great, thanks for confirmation on that, I'll fix the program so I don't need to make devices inside my cozy chroot and push the changes upstream. gabe.
