From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Securing "make check" (CVE-2014-0067) |
Date: | 2014-03-01 18:35:45 |
Message-ID: | 20140301183545.GA3407963@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-03-01 18:50:10 | Re: commit fest status and release timeline |
Previous Message | Magnus Hagander | 2014-03-01 18:20:52 | Re: Securing "make check" (CVE-2014-0067) |