Skip site navigation (1) Skip section navigation (2)

Re: Spoofing as the postmaster

From: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
To: Trevor Talbot <quension(at)gmail(dot)com>, Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl>, Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>
Subject: Re: Spoofing as the postmaster
Date: 2007-12-24 03:57:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Stephen Frost wrote:
> * Trevor Talbot (quension(at)gmail(dot)com) wrote:
>> There are various platform-specific security features that might be
>> useful, like reserved port ranges and file permissions, but they are
>> so specific to the scenario they're designed for that it's hard to
>> create a generic solution that works well by default -- especially if
>> you want to run without requiring administrative privileges in the
>> first place.
> Agreed.  A guarentee that the process listening on a particular port is
> what you're expecting isn't something that upstream can give.  It needs
> to be done through some situation-specific mechanism.  There are a
> number of options here, of course: SSL, Kerberos, SELinux, even things
> like the tiger IDS.  Reserved ports really aren't all that great a
> solution in the end anyway, to be honest.
UNIX socket kernel credential passing was mentioned in an earlier post, 
but I didn't see it raised again. All of the above mechanisms still 
require a piece of information to validate "trust". SSL requires a copy 
of the public certificate. UNIX socket credential passing would be much 
cheaper to validate - all it requires is the userid or username.

I prefer UNIX sockets with kernel credential passing over TCP/IP with 
username/password or the more expensive SSL. I do not like storing 
passwords or private certificates in a place available to the web user, 
as other web users would then also have access. I do not have evidence, 
but I am under the impression that the TCP/IP stack incurs additional 
overhead on connect(), send(), recv(), and close() than UNIX sockets.

Yes, Java doesn't work with UNIX sockets - but both Perl and PHP do. The 
only reason Java doesn't is because Java itself doesn't support UNIX 
sockets, and the Java JDBC provider is pure-Java.

How expensive would it be to implement a "server_user" db open parameter 
that would perform reverse credential passing to validate? "dbname=XXX 
port=5432 server_user=postgres". If the server can't prove it is 
postgres through UNIX socket credential passing, it fails. Similarly, 
identd may be usable in reverse? I've seen many people claim identd is 
insecure - but it is secure if I am the one running it, is it not?


Mark Mielke <mark(at)mielke(dot)cc>

In response to


pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-12-24 04:33:39
Subject: Re: Spoofing as the postmaster
Previous:From: Stephen FrostDate: 2007-12-24 00:59:32
Subject: Re: Spoofing as the postmaster

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group