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]

Date:   Mon, 10 Jan 2022 17:44:03 -0800
From:   "Andy Lutomirski" <luto@...nel.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>,
        "Theodore Ts'o" <tytso@....edu>
Cc:     "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 2:19 PM, Jason A. Donenfeld wrote:
> On Mon, Jan 10, 2022 at 9:18 PM Theodore Ts'o <tytso@....edu> wrote:
>> In general, you need FIPS
>> certification for some specific use cases / application.  For example,
>> if you're going for PCI compliance, then you might only need FIPS
>> compliance for your OpenSSL library.  What the FIPS certification lab
>> might consider acceptable for its entropy for its DRBG is an
>> interesting question.  For some, simply having the OpenSSL library use
>> RDSEED or RDRAND might be sufficient.  Or it could talk to an actual
>> physical RNG device.
>>
>> So disabling getrandom() is probably not necessary, just so long as
>> you can demonstrate that the FIPS cryptographic module --- i.e., the
>> OpenSSL library --- is getting its entropy from an acceptable source.
>
> I don't know exactly what these people think they want, but what you
> say seems probably correct.
>
>> I suspect what's actually going on is that some enterprise customers
>> have FIPS complaince on a check-off list, and they aren't actually
>> getting a formal FIPS certification.  Or they only need something to
>> wave under the noses of their PCI certification company, and so the
>> question is what makes them happy.
>
> Right.
>
>> And this is why some FIPS certification have gotten by just *fine*
>> with a pure userspace OpenSSL library as their FIPS cryptographic
>> module.  Where you draw the line between a "blessed" entropy source
>> and one that's just hand-waving is really at the discretion of the
>> certification lab.
>
> Hah, probably correct.
>
> So, seen this way, and combined with the solution provided at [1] (or
> similar) for people who think they need something there, it seems like
> the FIPS people can likely get what they need without really needing
> to involve the kernel anyway.

Hmm, cute, but I think we can do a bit better. After all, this hack involves trusting a whole lot of code that is *not* intended for secrets to avoid having side channels.

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.

>
> Jason
>
> [1] https://lore.kernel.org/lkml/YdynXjhhuQfbYuSb@zx2c4.com/