Oh boy. Is it that time of the year again already?
In case the /dev/urandom initialisation is a necessity (or a best
practice), does it make sense to add it into busybox as an option or
as an application?
So, there are two different things to address here:
1. the way to add entropy to the kernel's entropy pool in order to
make /dev/urandom sufficiently unpredictable;
2. the best way to do this as part of a boot process.
For the first thing, the problem is that writing to /dev/urandom adds
data to the seed, but does not update the entropy count, because the
data you write is not considered creditable (i.e. does not come from a
source that is considered random enough to warrant increasing the
entropy count).
That is the reason for the ioctl: to mark some random data as
creditable.
That is (a part of) why Jason, who revamped the entire random subsystem
in the Linux kernel, wrote seedrng[1].
(Unfortunately, he did not approve the modifications to the version of
seedrng that made it into busybox, so use bb seedrng at your own risk.
I have an alternative implementation of the same concept, rngseed[2],
that follows Jason's design more closely, and has additional options
to give more flexibility for e.g. systems with read-only boot disks.)
The answer's to Roberto's first question is: yes, initializing
/dev/urandom is necessary, but writing stuff to /dev/urandom will not
help, even if you consider that stuff random enough. You need a specific
tool like seedrng.
For the second thing: most of the initialization of a system can happen
while the seeding of the entropy pool is in progress. However, at some
point, you need a good source of randomness, e.g. when starting an sshd
server, and you should have a tool that makes sure the entropy pool is
full *before* important services start using it to get their random
data.
seedrng, or rngseed, fill that role. Writing data to /dev/urandom does
not. So the answer to Roberto's second question is: no, the provided
script excerpt is *not* suitable for seeding the entropy pool, no matter
how much compression, or even how much hashing, you use.
On that point, busybox cannot help here. busybox has an implementation
of seedrng, but it does not provide a full boot sequence or policy
whatsoever; it cannot tell *when* during boot it is appropriate to call
seedrng. It is all up to system integrators to write boot sequences that
seed the entropy pool correctly and start services securely.
[1]: https://git.zx2c4.com/seedrng/about/
[2]: https://skarnet.org/software/s6-linux-utils/rngseed.html
--
Laurent
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
