Re: why getrandom blocking does not work with /dev/urandom

[Stephan Mueller <smueller@chronox.de>]

Am Samstag, 22. Oktober 2016, 01:10:26 CEST schrieb Theodore Ts'o:

Hi Theodore,

> In any case, yes, you're not telling me anything I didn't know.  What
> I didn't know and still don't know is *why* systemd is tryinig to read
> from /dev/urandom.  e.g., is it trying to initialize cryptographic
> keys, the better to allow the Russians or the Chinese to set up
> botnets which can take over IOT devices and paralyze root nameservers?
> Or is it reading /dev/urandom for purely stupid, pointless,
> non-cryptographic reasons?

I thought that this was already clear given the following comment in systemd 
(function dev_urandom which is invoked by other code parts within systemd):

        /* Gathers some randomness from the kernel. This call will
         * never block, and will always return some data from the
         * kernel, regardless if the random pool is fully initialized
         * or not. It thus makes no guarantee for the quality of the
         * returned entropy, but is good enough for our usual usecases
         * of seeding the hash functions for hashtable */

So, using /dev/urandom is for noncryptographic purposes. The interesting thing 
however is that the code has the getrandom syscall invocation which seems that 
it is not used.


Aside from seeding hash tables, the mentioned function is also used for the 
following purposes:

- seed to generate a UUID (sd_id128_randomize) -- even in the code, comments 
are present that mention that the UUID generation code has been taken from the 
kernel. Thus, to circumvent the opening of /dev/urandom in this case, /proc/
sys/kernel/random/uuid should be used

- some namespace setup code pulls data from /dev/urandom (uid_shift_pick) -- 
again I cannot see a cryptographic use case

- random numbers are used for some DNS related use cases 
(dns_scope_make_conflict_packet, dns_scope_notify_conflict, pick_new_id) -- 
again, no crypto use case

- the creation of some random host name uses /dev/urandom 
(manager_next_hostname)

- get a random MAC address uses /dev/urandom (get_mac)


All in all, I see no cryptographic use case for any of the calls to /dev/
urandom. So, I would think that systemd can be improved to not pull /dev/
urandom at least during boot time.

Yet, even when systemd is updated, I fear that we cannot update the kernel to 
block /dev/urandom as it would break older systemd setups.

Ciao
Stephan