Message-ID: <Pine.BSM.4.64L.1805132113450.15657@herc.mirbsd.org>
Date:   Sun, 13 May 2018 21:23:39 +0000 (UTC)
From:   Thorsten Glaser <tg@...bsd.de>
To:     Adrian Bunk <bunk@...ian.org>
cc:     Ben Hutchings <ben@...adent.org.uk>,
        Debian release team <debian-release@...ts.debian.org>,
        Debian kernel maintainers <debian-kernel@...ts.debian.org>,
        krb5@...kages.debian.org, libbsd@...kages.debian.org,
        systemd@...kages.debian.org,
        Michael Kerrisk <mtk.manpages@...il.com>,
        "Theodore Ts'o" <tytso@....edu>, linux-kernel@...r.kernel.org
Subject: Re: Fixing Linux getrandom() in stable

Adrian Bunk dixit:

>As an example, what happens if I debootstrap and deploy the resulting
>filesytem to a large number of identical embedded systems without
>entropy sources?

Just get into a habit of not doing so, for example by modifying the
image during each writing process.

Having the bootloader inject entropy into the kernel would of course
help (something OpenBSD actually did, which I’d dreamt of only until).
Reuse is only problematic then if the system actually booted, i.e. an
early userspace thing reading and immediately writing to a file will
stave off the remaining issues.

>As far as I can see, any solution above would either give me boot hangs
>or might result in nasty security issues due to the same (known) entropy
>being fed to /dev/random on many machines.
>
>Similar problems for cases like live CDs and installers.

And CPUs, and architectures, without usable boot entropy.

For the “CD image” case, though, adding stuff like the MAC addresses
of the onboard NICs and the current time would at least shuffle the
existing (albeit known) entropy around enough for it to begin to differ.

A web service for getting random bits sounds like an idea, until you
get to the privacy implications of that (as well as reliability). But
if it’s inhouse, it’s doable.

>I wonder whether the current issue is just the tip of the iceberg,
>and usage of /dev/urandom is a gazillion CVEs waiting to be reported.

Did you see the fallback code for Linux in OpenBSD’s code for libbsd?
It’s… like trying to find randomly-looking things on an 1990s Unix.

This is best fixed in the kernel and earlier, plus an extra read/write
in early userspace. Of course, embedding some entropy into the kernel
image itself will make the reproducible-builds people entirely unhappy…
(this one *is* implemented in MirBSD, complete with a tool to update
it).

>Due to the gdm bugs mentioned above we know that there are real-life
>situations where gdm currently uses "random" data that might be
>predictable.

The question is which uses actually need entropy estimated good enough?

>>    b. Tolerate a longer wait for getrandom() to return
>
>I suspect there might be no guaranteed upper bound for the waiting time.

On a discless system with no hardware sources (possibly no network)
and no keyboard interaction? Infinite.

Of course, if early userspace could reliably update a file, then the
file’s content could be estimated as good enough and be credited to
the RNG, at least for non-identical/readonly-/shared-media systems.

>never block but might return predictable data in some cases.

“What level of predictability?”

>It would then be up to the application to decide whether predictable
>data is acceptable, and what to do in entropy-starved situations.

I guess most application authors have no answer for you here.

It’s also no solution for the arc4random API… seems like a cultural
clash (BSD expectations vs. what Linux can actually deliver).

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool.”
						-- Edward Burr

Powered by blists - more mailing lists