4 ms·
With OpenSSL, if you know you're going be chrooting, you can explicitly seed the internal PRNG with a call to RAND_poll() before you chroot, avoiding the need t
by agwa 12y ago
With OpenSSL, if you know you're going be chrooting, you can explicitly seed the internal PRNG with a call to RAND_poll() before you chroot, avoiding the need to open /dev/urandom once you've chrooted. (Similarly, you're supposed to call RAND_poll() to re-seed after forking because there's no safe way to detect that you've forked. Of course, if you fork while in a chroot you're screwed.)
I really think that LibreSSL's RAND_poll() should have similar behavior to ensure maximum compatibility with OpenSSL and to provide a means to use chroot() safely without the risk of falling back to the "bobo" code. (Also, a means of safely reseeding after a fork on systems without minherit(MAP_INHERIT_ZERO)).
(Incidentally, libsodium has a similar API: you can explicitly call randombytes_stir() to cause the library to open (and keep open) a file descriptor to /dev/urandom, so subsequent calls to the PRNG work in a chroot.)
- tedunangst 12y agoYes, that's what you're supposed to do, and it sucks. A good library should provide you with more than a box full of hammers and thumbs; it should actually help you and not just punt whenever a hard decision shows up. The RAND interface was one of the first things gutted. The presence or need for a stir() function should be considered a serious design flaw. (forks are detected by calling getpid() if you don't have inheritzero.)
- agwa 12y agoAgreed, but the lack of a random syscall on Linux makes an API like stir necessary. Also, getpid() isn't airtight - if you fork and fork again there's a risk of PID wraparound.