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

From Noah Misch
Subject Re: Securing "make check" (CVE-2014-0067)
Date
Msg-id 20140608135713.GA525142@tornado.leadboat.com
Whole thread Raw
In response to Re: Securing "make check" (CVE-2014-0067)  (Noah Misch <noah@leadboat.com>)
Responses Re: Securing "make check" (CVE-2014-0067)  (Christoph Berg <cb@df7cb.de>)
List pgsql-hackers
On Sun, Mar 23, 2014 at 07:04:20PM -0400, Noah Misch wrote:
> On Thu, Mar 06, 2014 at 11:52:22PM -0500, Noah Misch wrote:
> > On Thu, Mar 06, 2014 at 12:44:34PM -0500, Tom Lane wrote:
> > > I'm inclined to suggest that we should put the socket under $CWD by
> > > default, but provide some way for the user to override that choice.
> > > If they want to put it in /tmp, it's on their head as to how secure
> > > that is.  On most modern platforms it'd be fine.
> >
> > I am skeptical about the value of protecting systems with non-sticky /tmp, but
> > long $CWD isn't of great importance, either.  I'm fine with your suggestion.
> > Though the $CWD or one of its parents could be world-writable, that would
> > typically mean an attacker could just replace the test cases directly.
>
> Here's the patch.  The temporary data directory makes for a convenient socket
> directory; initdb already gives it mode 0700, and we have existing
> arrangements to purge it when finished.  One can override the socket directory
> by defining PG_REGRESS_SOCK_DIR in the environment.

Socket path length limitations thwarted that patch:
http://www.postgresql.org/message-id/flat/E1WTnV2-00047S-NM@gemulon.postgresql.org

Here's an update that places the socket in a temporary subdirectory of /tmp.
The first attached patch adds NetBSD mkdtemp() to libpgport.  The second,
principal, patch uses mkdtemp() to implement this design in pg_regress.  The
corresponding change to contrib/pg_upgrade/test.sh is based on the "configure"
script's arrangements for its temporary directory.

NetBSD's mkdtemp() has assertions, and I initially mapped its assertion macro
to our Assert().  However, a bug in our MinGW build process causes build
failures if an Assert() call appears in libpgport.  I will post about that in
a new thread.  The affected assertions were uncompelling, so I dropped them.

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

Attachment

pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Scaling shared buffer eviction
Next
From: Eric L
Date:
Subject: configure does not check for bison or flex