Re: Spoofing as the postmaster

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?

Cheers,
mark

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