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: <20190915093057.GF20811@1wt.eu>
Date:   Sun, 15 Sep 2019 11:30:57 +0200
From:   Willy Tarreau <w@....eu>
To:     Lennart Poettering <mzxreary@...inter.de>
Cc:     "Ahmed S. Darwish" <darwish.07@...il.com>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        Michael Kerrisk <mtk.manpages@...il.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>, linux-ext4@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC v3] random: getrandom(2): optionally block when CRNG
 is uninitialized

On Sun, Sep 15, 2019 at 10:59:07AM +0200, Lennart Poettering wrote:
> We live in a world where people run HTTPS, SSH, and all that stuff in
> the initrd already. It's where SSH host keys are generated, and plenty
> session keys.

It is exactly the type of crap that create this situation : making
people developing such scripts believe that any random source was OK
to generate these, and as such forcing urandom to produce crypto-solid
randoms! No, distro developers must know that it's not acceptable to
generate lifetime crypto keys from the early boot when no entropy is
available. At least with this change they will get an error returned
from getrandom() and will be able to ask the user to feed entropy, or
be able to say "it was impossible to generate the SSH key right now,
the daemon will only be started once it's possible", or "the SSH key
we produced will not be saved because it's not safe and is only usable
for this recovery session".

> If Linux lets all that stuff run with awful entropy then
> you pretend things where secure while they actually aren't. It's much
> better to fail loudly in that case, I am sure.

This is precisely what this change permits : fail instead of block
by default, and let applications decide based on the use case.

> Quite frankly, I don't think this is something to fix in the
> kernel.

As long as it offers a single API to return randoms, and that it is
not possible not to block for low-quality randoms, it needs to be
at least addressed there. Then userspace can adapt. For now userspace
does not have this option just due to the kernel's way of exposing
randoms.

Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ