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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3344810.FOR7goHsm1@positron.chronox.de>
Date:   Sun, 23 Oct 2016 16:09:50 +0200
From:   Stephan Mueller <smueller@...onox.de>
To:     Theodore Ts'o <tytso@....edu>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: why getrandom blocking does not work with /dev/urandom

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