linux-kernel - 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]

Date:   Mon, 16 Sep 2019 10:44:31 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Willy Tarreau <w@....eu>, Vito Caputo <vcaputo@...garu.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        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

On Mon, Sep 16, 2019 at 10:21 AM Theodore Y. Ts'o <tytso@....edu> wrote:
>
> We could create a new flag, GRND_INSECURE, which never blocks.  And
> that that allows us to solve the problem for silly applications that
> are using getrandom(2) for non-cryptographic use cases.

Note that getting "reasonably good random numbers" is definitely not silly.

If you are doing things like just shuffling a deck of cards for
playing solitaire on your computer, getting a good enough source of
randomness is nontrivial. Using getrandom() for that is a _very_ valid
use. But it obviously does not need _secure_ random numbers.

It is, in fact, _so_ random that we give that AT_RANDOM thing to every
new process because people want things like that. Sadly, people often
aren't aware of it, and don't use that as much as they could.

(Btw, we should probably also mix in other per-process state, because
right now people have actually attacked the boot-time AT_RANDOM to
find canary data etc).

So I think you are completely out to lunch by calling these "insecure"
things "silly". They are very very common. *WAY* more common than
making a long-term secure key will ever be. There's just a lot of use
of reasonable randomness.

You also are ignoring that we have an existing problem with existing
applications. That happened exactly because those things are so
common.

So here's my suggestion:

 - admit that the current situation actually causes problems, and has
_existing_ bugs.

 - throw it out the window, with the timeout and big BIG warning when
the problem cases trigger

 - add new GRND_SECURE and GRND_INSECURE flags that have the actual
useful behaviors that we currently pretty much lack

 - consider the old 0-3 flag values legacy, deprecated, and unsafe
because they _will_ time out to fix the existing problem we have right
now because of their bad behavior.

And stop with the "insecure is silly". Insecure is not silly, and in
fact should have been the default, because

 (a) insecure is and basically always will be the common case by far

 (b) insecure is the "not thinking about it" case and should thus be default

and that (b) is also very much why 0 should have been that insecure case.

Part of the problem is exactly the whole "_normally_ it just works, so
using 0 without thinking about it tests out well".

Which is why getrandom(0) is the main problem we face.

Because defaults matter.

               Linus