Re: Securing "make check" (CVE-2014-0067) - Mailing list pgsql-hackers

On Sat, Mar 01, 2014 at 12:29:38PM -0500, Tom Lane wrote:
> There are two big problems with the lets-generate-a-random-password
> approach.  Noah acknowledged the portability issue of possibly not having
> a strong entropy source available.  The other issue though is whether
> doing this doesn't introduce enough crypto dependency into the core code
> to create an export-restrictions hazard.  We've kept contrib/pgcrypto
> out of core all these years in order to give people a relatively
> straightforward solution if they are worried about export laws: just omit
> contrib/pgcrypto.  But "just omit regression testing" isn't palatable.

If pgrand.c poses an export control problem, then be-secure.c poses a greater
one.  pgrand.c is just glue to an OS-provided CSPRNG.

> In the case of Unix systems, there is a *far* simpler and more portable
> solution technique, which is to tell the test postmaster to put its socket
> in some non-world-accessible directory created by the test scaffolding.
> 
> Of course that doesn't work for Windows, which is why we looked at the
> random-password solution.  But I wonder whether we shouldn't use the
> nonstandard-socket-location approach everywhere else, and only use random
> passwords on Windows.  That would greatly reduce the number of cases to
> worry about for portability of the password-generation code;

Further worrying about systems lacking /dev/urandom is a waste of time.  They
will only get less common, and they are already rare enough that we have zero
of them on the buildfarm.  I provided them with a straightforward workaround:
point the PGTESTPWFILE environment variable to a file containing a password.

Having that said, I can appreciate the value of tightening the socket mode for
a bit of *extra* safety:

--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -2299,4 +2299,5 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
fputs("\n#Configuration added by pg_regress\n\n", pg_conf);        fputs("max_prepared_transactions = 2\n", pg_conf);
 
+        fputs("unix_socket_permissions = 0700\n", pg_conf);

Taking the further step of retaining trust authentication on Unix would make
it easier to commit tests guaranteed to fail on Windows.  I see no benefit
cancelling that out.

> and perhaps
> we could also push the crypto issue into reliance on some Windows-supplied
> functionality (though I'm just speculating about that part).

Every version of the patch has done it that way.  It has used OS-supplied
cryptography on every platform.

nm

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com