linux-kernel - Re: [PATCH v43 01/15] Linux Random Number Generator

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Ydz1F/AqB1oO/qHF@mit.edu>
Date:   Mon, 10 Jan 2022 22:10:15 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
        Simo Sorce <simo@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jeffrey Walton <noloader@...il.com>,
        Stephan Mueller <smueller@...onox.de>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Willy Tarreau <w@....eu>, Nicolai Stange <nstange@...e.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Vito Caputo <vcaputo@...garu.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        zhangjs <zachary@...shancloud.com>,
        Florian Weimer <fweimer@...hat.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        Peter Matthias <matthias.peter@....bund.de>,
        Neil Horman <nhorman@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Julia Lawall <julia.lawall@...ia.fr>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Andy Lavr <andy.lavr@...il.com>,
        Petr Tesarik <ptesarik@...e.cz>,
        John Haxby <john.haxby@...cle.com>,
        Alexander Lobakin <alobakin@...lbox.org>,
        Jirka Hladky <jhladky@...hat.com>,
        Eric Biggers <ebiggers@...nel.org>
Subject: Re: [PATCH v43 01/15] Linux Random Number Generator

On Mon, Jan 10, 2022 at 05:44:03PM -0800, Andy Lutomirski wrote:
> 
> So let’s solve it for real.  Have a driver (in a module) that
> exposes a /dev/urandom compatible interface to the CryptoAPI DRBG.
> We can do a really nice job of it, and maybe it’ll be 100 lines of
> code.  People can do whatever they like with it in their container
> manager or boot scripts. And if it has a problem (where it’s *less*
> secure than the real urandom), we can say “I told you so”.
> 
> We can go one step farther: add an LSM hook to getrandom().  Then
> someone can hack up a fips_t policy for SELinux that turns off
> getrandom.

These are both dangerous.  The first means creating a new device node
which effectively is /dev/drbg-random which could be bind mounted or
mknod'ed to be /dev/urandom.  But if the user boots a kernel that
doesn't support this new device node, it will mean opening
/dev/urandom will get ENODEV.

Similarly, getrandom(2) never fails.  By allowing a SELinux policy to
force it to fail with ENOSYS, or some other error, it means exposing
userspace code to a failure path that may not be as well tested.
Sure, *sane* code might fall back to opening /dev/urandom; but the
whole point of getrandom(2) was that it was a dumb, stupid interface
interface that could be safely used by application programmers.  Not
paranoid OS crypto engineers that carefully check the error returns of
all system calls, with appropriate fallbacks and making sure that code
always "fails safe".

Right now, the enterprise distros are doing their own thing, and quite
frankly, I don't see a problem with that.  If it turns out DRBG is
less secure (and there are some things that fill me with disquiet),
then let them take the economic consequences, since they are the ones
who are doing this for the economic advantages of trying to claim FIPS
compliance.

If we must support this in the upstream kernel, then configure it via
CONFIG_RANDOM_SECURITY_THEATRE which redirects getrandom(2) and
/dev/[u]random to DRBG.  I'd prefer that it be possible for someone to
put "random_security_theatre=0" on the boot command line which would
disable redirecting the interfaces to DRBG so if it turns out that
DRBG *is* less secure, we can give advice on how to turn it off
without requiring a patched kernel.  :-)

						- Ted