Re: Spoofing as the postmaster

"D'Arcy J.M. Cain" <darcy(at)druid(dot)net> writes:

> On Sat, 22 Dec 2007 09:25:05 -0500 (EST)
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> I think at a minimum we need to add documentation that states if you
>> don't trust the local users on the postmaster server you should:
>>
>> o create unix domain socket files in a non-world-writable
>> directory
>> o require SSL server certificates for TCP connections
>>
>> Ideas?
>
> It's generally a bad idea to put your database on a public server
> anyway but if you do you should definitely disable unix domain sockets
> and connect over TCP to localhost. That has been our rule for years.
>
> It's certainly a corner case. I would think that warnings, perhaps in
> the config file itself, would be sufficient.

That seems like a terrible idea. At least while you're dealing with unix
domain sockets you know there's no way a remote user could possibly interfere
with or sniff your data. As soon as you're dealing with TCP it's a whole new
ballgame.

X famously had a problem on many OSes where you could spoof the first packet
(and if you could predict sequence numbers more than that) of a connection
allegedly coming from 127.0.0.1. (it helped that a message to open up
connections from anywhere fit in one packet...) Modern OSes include network
filters to block such spoofs but it's one more thing you're counting on.

Also brought into place are things like forged RST packets, routing table
attacks, and on and on.

And on the performance front you're dealing with smaller mss and much higher
protocol overhead. You also lose bulletproof authentication from unix
credentials and are instead relying on properly configuring your network
authentication. And it's much easier to accidentally be relying on insecure
identd.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!