* Heikki Linnakangas (hlinnaka@iki.fi) wrote:
> 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..
If it is, then that's certainly tempting, especially if that's the only
platform we support where we don't have a better option, and we wish to
continue supporting it.
> > 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.
Wouldn't it be possible to make this a build-time question..? I don't
particularly like the idea of pg_strong_random() falling back to
not-strong values, but maybe we could have a '--use-weak-random'
configure switch for platforms that don't provide a strong source.
Then again, if we wish to support this platform, then perhaps we should
put in the effort to support prngd.
Thanks!
Stephen
