On Mon, Sep 16, 2019 at 10:21 AM Theodore Y. Ts'o <[email protected]> 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
> - 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.
Just for the record because I did not see it mentioned in this thread,
this patch by Andy Lutomirski, posted two weeks ago, adds GRND_INSECURE
and makes GRND_RANDOM a no-op:
https://lore.kernel.org/lkml/[email protected]/
On Mon, Sep 16, 2019 at 10:44:31AM -0700, Linus Torvalds wrote:
> - 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.
I think we can keep a flag to work like the current /dev/random and
deplete entropy for the very rare cases where it's really desired
to run this way (maybe even just for research), but it should require
special permissions as it impacts the whole system.
I think that your GRND_SECURE above means the current 0 situation,
where we wait for initial entropy then not wait anymore, right ? If
so it could remain the default setting, because at least it will not
betray applications which rely on this reliability. And GRND_INSECURE
will be decided on a case by case basis by applications that are caught
waiting like sfdisk in initramfs or a MAC address generator for example.
In this case it could even be called GRND_PREDICTABLE maybe to enforce
its property compared to others.
My guess is that we can fix the situation because nobody likes the
problems that sporadically hit users. getrandom() was adopted quite
quickly to solve issues related to using /dev/*random in chroots,
I think the new flags will be adopted by those experiencing issues.
Just my two cents,
Willy
On Mon, Sep 16, 2019 at 10:44:31AM -0700, Linus Torvalds wrote:
> - 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
The semantics many people want for secure key generation is urandom, but
with a guarantee that it's seeded. getrandom()'s default behaviour at
present provides that, and as a result it's used for a bunch of key
generation. Changing the default (even with kernel warnings) seems like
it risks people generating keys from an unseeded prng, and that seems
like a bad thing?
It's definitely unfortunate that getrandom() doesn't have a GRND_URANDOM
flag that would make it useful for the "I want some vaguely random
numbers but I don't care that much and I don't necessarily have access
to /dev/urandom" case, but at the moment we have no way of
distinguishing between applications that are making this call because
they want the semantics of urandom but need it to be seeded (which is
one of the usecases getrandom() was introduced for in the first place)
and applications that are making this call because it was convenient and
the kernel usually ended up generating enough entropy in the first
place. Given the ambiguity, I don't see an easy way to solve for the
latter without breaking the former - and that could have some *very* bad
outcomes.
--
Matthew Garrett | [email protected]