If there is no hardware entropy device recognized by /etc/init.d/rngd, it falls back to using /dev/urandom to seed the kernel entropy pool. This is dangerous. I installed rng-tools to make use of my VIA (CentaurHauls) C7's hardware RNG, however the /etc/init.d/rngd of a previous version (presumably whatever corresponds to $Header: /var/cvsroot/gentoo-x86/sys-apps/rng-tools/files/2/rngd,v 1.1 2006/03/20 09:33:00 nelchael Exp $) does not recognize /dev/hwrng. In this case, the default behaviour effectively /usr/sbin/rngd -r /dev/urandom, which feeds /dev/urandom back into /dev/random. This compromises any program which expects the output of /dev/random to have 8 bits of entropy per byte. The only possible benefit of this "feature" is that it reduces the time that programs are blocked reading /dev/random, but this can also be achieved by configuring those programs to use /dev/urandom instead (which is better since it doesn't result in context switching when the entropy pool is drained). It is safe to assume that users of /dev/random expect true entropy, not just random-looking bytes. Patch coming up. Reproducible: Always Steps to Reproduce: # mv /dev/hwrng{,_} # /etc/init.d/rngd restart Actual Results: * Stopping hardware RNG daemon ... [ ok ] * Starting hardware RNG daemon ... * No hardware RNG found, using /dev/urandom as feedback input [ ok ] Expected Results: * Stopping hardware RNG daemon ... [ ok ] * Starting hardware RNG daemon ... * Failed to start hardware RNG daemon: no hardware RNG found [ !! ]
Created attachment 209520 [details, diff] /etc/init.d/rngd patch I heard you liked entropy, so I mixed your entropy pool into your entropy pool so you can generate pseudorandom numbers while you generate pseudorandom numbers!
2-r3 now updated to make remix of /dev/urandom optional.
So, the "fix" is # Bug #292239: Remixing /dev/urandom back into /dev/random is considered a # security vulnerability in some cases where not enough entropy is present on # systems. DO_NOT_REMIX_URANDOM=0 I'm afraid this isn't good enough; mixing /dev/urandom into /dev/random is always wrong: - Programs that read from /dev/random expect "good" entropy. - Programs that care more about performance should read from /dev/urandom. - Admins who want everything to run faster can change /dev/random to point to /dev/urandom with udev or mknod or ln -s. This has much less overhead than mixing /dev/urandom into itself (/dev/random only seems to return 128 bytes at a time). There is simply no case where mixing /dev/urandom into /dev/random is a good idea. I'd be happier with a "feature" that pointed /dev/urandom to /dev/random. Additionally, the ebuild description is "Daemon to use hardware random number generators". People install rng-tools because the have a hwrng which they wish to use, not because they think /dev/random is too slow.
http://n0tablog.wordpress.com/2007/11/24/running-out-of-entropy-in-debian-etch/ discusses precisely how to make /dev/random point to /dev/urandom using either symlinks or udev, with a warning attached: Understand this: your system will become somewhat less secure as a result. This is your choice. Do your homework and understand the consequences. You are the only person who cares enough.
I'm going to change the default for this to be disabled by default, as it spells trouble where rdrand is available (it'll be mixing /dev/urandom by default even if something stronger is there). This should be enough, as a default. For those who really want some other source of entropy and don't have an HWRNG we can suggest timer_entropyd or haveged. We have quite a few entropy sources at this point.
Actually, with the latest init script now the whole comment about it is gone. If any user wants to set the device to /dev/urandom explicitly, it's their call, but it'll _never_ be used by default. So, security, what you want to do with this?
This bug should be closed. The specified version is not in the tree anymore. Furthermore, the upstream code never attempted to use '/dev/urandom' by default. It was the Gentoo provided init script that caused the bug[1], and later addressed by a dev[2]. [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/rng-tools/files/2/rngd?hideattic=0&view=markup [2] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/rng-tools/files/2-r2/rngd?hideattic=0&revision=1.2&view=markup
@security: please close this issue.