On Mon, Sep 16, 2019 at 10:21 AM Theodore Y. Ts'o <tytso@xxxxxxx> 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
