Re: Securing "make check" (CVE-2014-0067)

Dave Page <dpage@pgadmin.org>

From: Dave Page <dpage@pgadmin.org>
To: Noah Misch <noah@leadboat.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Tom Lane <tgl@sss.pgh.pa.us>, Magnus Hagander <magnus@hagander.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2014-03-02T07:29:57Z
Lists: pgsql-hackers

> On 2 Mar 2014, at 05:20, Noah Misch <noah@leadboat.com> wrote:
> 
>> On Sat, Mar 01, 2014 at 05:51:46PM -0500, Andrew Dunstan wrote:
>>> On 03/01/2014 05:10 PM, Tom Lane wrote:
>>> One other thought here: is it actually reasonable to expend a lot of effort
>>> on the Windows case?  I'm not aware that people normally expect a Windows
>>> box to have multiple users at all, let alone non-mutually-trusting users.
>> 
>> As Stephen said, it's fairly unusual. There are usually quite a few
>> roles, but it's rare to have more than one "human" type role
>> connected to the machine at a given time.
> 
> I, too, agree it's rare.  Rare enough to justify leaving the vulnerability
> open on Windows, indefinitely?

It's not that rare in my experience - certainly there are far more single user installations, but Terminal Server configurations are common for deploying apps "Citrix-style" or VDI. The one and only Windows server maintained by the EDB infrastructure team is a terminal server for example.

>  I'd say not.  Windows itself has been pushing
> steadily toward better multi-user support over the past 15 years or so.
> Releasing software for Windows as though it were a single-user platform is
> backwards-looking.  We should be a model in this area, not a straggler.

Definitely.

> 
>> I'd be happy doing nothing in this case, or not very much. e.g.
>> provide a password but not with great cryptographic strength.
> 
> One option that would simplify things is to fix only non-Windows in the back
> branches, via socket protection, and fix Windows in HEAD only.  We could even
> do so by extending HAVE_UNIX_SOCKETS support to Windows through named pipes.
> 
> Using weak passwords on Windows alone would not simplify the effort.
> 
> -- 
> Noah Misch
> EnterpriseDB                                 http://www.enterprisedb.com
> 
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Have config_sspi_auth() permit IPv6 localhost connections.

  2. Lock down regression testing temporary clusters on Windows.

  3. Use a separate temporary directory for the Unix-domain socket

  4. Secure Unix-domain sockets of "make check" temporary clusters.