linux-ext4 - Re: Linux 5.3-rc8

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: <20190916042952.GB23719@1wt.eu>
Date:   Mon, 16 Sep 2019 06:29:52 +0200
From:   Willy Tarreau <w@....eu>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Vito Caputo <vcaputo@...garu.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Lennart Poettering <mzxreary@...inter.de>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        zhangjs <zachary@...shancloud.com>, linux-ext4@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8

Hi Ted,

On Sun, Sep 15, 2019 at 10:49:04PM -0400, Theodore Y. Ts'o wrote:
> No matter *what* we do, it's going to either (a) make some
> systems insecure, or (b) make some systems more likely hang while
> booting.

I continue to strongly disagree with opposing these two. (b) is
caused precisely because of this conflation. Life long keys are
produced around once per system's life (at least this order of
magnitude). Boot happens way more often. Users would not complain
that systems fail to start if the two types of random are properly
distinguished so that we don't fail to boot just for the sake of
secure randoms that will never be consumed as such.

Before systems had HWRNGs it was pretty common for some tools to
ask the user to type hundreds of characters on the keyboard and
use that (content+timings) to feed entropy while generating a key.
This is acceptable once in a system's life. And on some systems
with no entropy like VMs, it's commonly generated from a central
place and never from the VM itself, so it's not a problem either.

In my opinion the problem recently happened because getrandom()
was perceived as a good replacement for /dev/urandom and is way
more convenient to use, so applications progressively started to
use it without realizing that contrary to its ancestor it can
block. And each time a system fails to boot confirms that entropy
still remains a problem even on PCs in 2019. This is one more
reason for clearly keeping two interfaces depending on what type
of random is needed.

I'd be in favor of adding in the man page something like "this
random source is only suitable for applications which will not be
harmed by getting a predictable value on output, and as such it is
not suitable for generation of system keys or passwords, please
use GRND_RANDOM for this". This distinction currently is not clear
enough for people who don't know this subtle difference, and can
increase the interface's misuse.

Regards,
Willy