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: <CAHmME9o8FFLC3vvTN0cNzdzoYvBFwJMUCTaxOhnXfTaEELbBeg@mail.gmail.com>
Date:   Tue, 11 Jan 2022 14:16:30 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     Andy Lutomirski <luto@...nel.org>,
        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

Hi Ted,

On Tue, Jan 11, 2022 at 4:12 AM Theodore Ts'o <tytso@....edu> wrote:
> 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.

I agree with you. I think enterprise distros ought to keep doing their
own thing here, and there's a clear solution that does this in
userspace, and also a pretty non-invasive patch from Marcelo to patch
the crap into the kernel need be.

I spent some time reading about FIPS certification, compliance, and
the requirements of various customers. One thing in particular leapt
out at me, which I think you've been saying over and over in this
thread but I didn't fully understand until this morning:

The goal is generally to have particular pieces of software or
particular solutions FIPS certified. And to do this, they start from
the top of the stack and move onward down. Most OSS software out there
today isn't really FIPS ready and oftentimes a full solution needs
modifications in one place or another. Other times, it's enough to
plug in the right userspace crypto libraries. And I noticed in looking
at things that are FIPS certified that random number generation tends
to go through a userspace abstraction layer. And, it looks like these
abstraction layers all have FIPS-able RNG hooks. You mentioned OpenSSL
earlier, and it looks like even libgcrypt and wolfSSL have an
abstraction layer for this.

In other words, it's not even so clear that people who need FIPS
compliance really need /dev/urandom and such to be FIPS compliant as
part of that. And the ones who think they do for whatever security
theater nonsense can happily load up that CUSE thing I made, apply a
deliberately-downstream patch, or whatever other clever solution.

So indeed it really doesn't seem like this is something the kernel
needs to be doing.

Jason