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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Securing "make check" (CVE-2014-0067)
Дата
Msg-id CA+TgmoZPPhwy1bRsOY+7QgDgtORZg1VjK+bmZ6Kc+uwtJHRZ-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Securing "make check" (CVE-2014-0067)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Mar 31, 2014 at 3:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Mar 30, 2014 at 3:52 PM, Christoph Berg <cb@df7cb.de> wrote:
>>> Oh, right. There's this other patch which apparently works so well
>>> that I already forgot it's there:
>>>
>>> Enable pg_regress --host=/path/to/socket:
>>>
https://alioth.debian.org/scm/loggerhead/pkg-postgresql/postgresql-9.4/trunk/view/head:/debian/patches/60-pg_regress_socketdir.patch
>
>> Wasn't this patch submitted for inclusion in PostgreSQL at some point?
>>  Did we have some good reason for not accepting it?
>
> Well, other than very bad coding style (casual disregard of the message
> localizability guidelines, and the dubious practice of two different
> format strings in one printf call) it doesn't seem like a bad idea on
> its face to allow pg_regress to set a socket path.  But do we want
> pg_regress to *not* specify a listen_addresses string?  I think we
> are currently setting that to empty intentionally on non-Windows.
> If it defaults to not-empty, which is what I think will happen with
> this patch, isn't that opening a different security hole?

Good points...

> I think we need a somewhat larger understanding of what cases we're trying
> to support, in any case ...

My impression is that some people just want the postmaster that gets
started for the pg_regress runs to listen on a socket rather than a
port.  Obviously that won't work on Windows, but it seems like a
pretty reasonable thing to want to do everywhere else, especially in
light of the security issues around make check we've been discussing.
There's not going to be any convenient, cross-platform, unprivileged
way of preventing other applications on the same system from
connecting to a local TCP socket, whereas with a UNIX socket you can
nail that door shut pretty tight using filesystem permissions.  That
isn't to say that you can't secure the TCP socket, but it's gotta be
done through the user auth methods and is only as good as those
methods are.  I think an adequate solution can be achieved that way,
but with the UNIX socket method the attack surface area is a whole lot
more restricted, which seems appealing from where I sit.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christoph Berg
Дата:
Сообщение: Re: Securing "make check" (CVE-2014-0067)
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements