On 10/17/2016 05:50 PM, Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@iki.fi> writes:
>> Replace PostmasterRandom() with a stronger way of generating randomness.
>
> This patch broke padmeleon:
>
> 016-10-17 09:57:17.782 EDT [5804d8bd.57c2:1] LOG: database system was shut down at 2016-10-17 09:57:17 EDT
> 2016-10-17 09:57:17.790 EDT [5804d8bd.57c2:2] LOG: MultiXact member wraparound protections are now enabled
> 2016-10-17 09:57:17.807 EDT [5804d8bd.57c6:1] LOG: autovacuum launcher started
> 2016-10-17 09:57:17.820 EDT [5804d8bd.57bf:1] LOG: database system is ready to accept connections
> 2016-10-17 09:57:18.516 EDT [5804d8bd.57bf:2] LOG: could not generate random query cancel key
> 2016-10-17 09:57:19.544 EDT [5804d8bd.57bf:3] LOG: could not generate random query cancel key
> 2016-10-17 09:57:20.563 EDT [5804d8bd.57bf:4] LOG: could not generate random query cancel key
> 2016-10-17 09:57:21.584 EDT [5804d8bd.57bf:5] LOG: could not generate random query cancel key
> 2016-10-17 09:57:22.604 EDT [5804d8bd.57bf:6] LOG: could not generate random query cancel key
>
> It's failing because this machine lacks /dev/random and /dev/urandom.
> It does have a non-kernel entropy daemon (prngd), which OpenSSL knows how
> to read from but the hard-wired code in pg_strong_random() does not.
>
> I'm not sure whether it's worth trying to make pg_strong_random() aware
> of prngd.
Seems simple enough..
> The real issue here is whether we are willing to say that
> Postgres simply does not work anymore on machines without standard entropy
> sources. Doesn't matter whether the user cares about the strength of
> cancel keys, we're just blowing them off. That seems a bit extreme
> from here. I think we should be willing to fall back to the old code
> if we can't find a real entropy source.
I'm scared of having pg_strong_random() that is willing to fall back to
not-so-strong values. We can rename it, of course, but it seems
dangerous to use a weak random-number generator for authentication
purposes (query cancel, MD5 salts, SCRAM nonces).
I think both for the MD5 salt and SCRAM, it doesn't have to be
unpredictable to attackers, as long the attacker cannot influence it so
that a particular value is chosen. For query cancel, it needs to be
unpredictable, but the query cancel key is quite short anyway, and we
haven't worried about it so far anyway, because an attacker can't do
very much damage by just canceling queries.
One option would be to disable query-canceling and MD5 (and SCRAM)
authentication, if we don't have an entropy source.
- Heikki
