Thread: Localhost vs. Unix Domain Sockets?

On 8/18/2014 4:55 PM, Ken Tanzer wrote:
> So I've got two questions.  One is whether there are any downsides to
> using sockets, or any "gotchas" to be aware of.  The second is whether
> there is anything to do to increase the security of sockets?  (e.g.,
> analagous to encrypting localhost conenctions with SSL?)  From the
> little I saw, it sounds like sockets are "just inherently secure," but
> wanted to confirm that or get another opinion!

localhost is plenty secure, only root can sniff it, and root can su to
postgres and be in full ownership of your server anyways, so if you
consider root a security risk, well, there's no cure for that.

unix domain sockets are quite secure too.   they might be slightly
faster than tcp/ip via localhost, but its probably not enough to matter.



--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

John R Pierce <pierce@hogranch.com> writes:
> On 8/18/2014 4:55 PM, Ken Tanzer wrote:
>> So I've got two questions.  One is whether there are any downsides to
>> using sockets, or any "gotchas" to be aware of.  The second is whether
>> there is anything to do to increase the security of sockets?  (e.g.,
>> analagous to encrypting localhost conenctions with SSL?)  From the
>> little I saw, it sounds like sockets are "just inherently secure," but
>> wanted to confirm that or get another opinion!

> localhost is plenty secure, only root can sniff it, and root can su to
> postgres and be in full ownership of your server anyways, so if you
> consider root a security risk, well, there's no cure for that.

Well, there are two things here.  You're right that sniffing traffic on
an existing connection is probably about equivalently hard either way;
but making an unauthorized connection is a totally different issue.
On most OSes, any local process can attempt a connection to the
postmaster's localhost TCP port, so it's down to whether you have enough
faith in passwords to keep an attacker out of your database.  If you use
socket connections then you can make use of filesystem permissions as an
extra security layer, to limit the set of processes that even potentially
have access to the database.  Plus there's the possibility of using peer
authentication, as Ken says.

> unix domain sockets are quite secure too.   they might be slightly
> faster than tcp/ip via localhost, but its probably not enough to matter.

Yeah, I'd not expect much speed difference.  Most modern kernels have
short-circuit paths for local TCP connections, so that there's no extra
protocol overhead there.

            regards, tom lane

On 8/18/2014 5:45 PM, Ken Tanzer wrote:
> I used to have my db and linux usernames match, until this issue came
> along: http://www.postgresql.org/support/security/faq/2013-04-04/.  It
> specifically mentions potentially increased vulnerability if the names
> match.  So when I set up a new server I had them not match.  I know
> this particular issue is fixed.  But are there other ways that having
> the names match could potentially increase vulnerability (even if not
> known or identified yet), or am I pointlessly "fighting the last war"
> by keeping the names different?

afaik that exploit only applies when the user is coming in over tcp/ip



--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

On 8/18/2014 6:45 PM, Ken Tanzer wrote:
> Thanks.  I'm not really worried about this particular vulnerability,
> just wondering about the more general idea that having db user name =
> os user could reduce your security, even if only slightly.  Is it just
> as conceivable that a vulnerability could come along that was more
> exploitable only if the two names were _different_?

what I read on that vunerability, it was talking about dbuser == dbname,
not os user.   and frankly, I didn't get their rationale for that.



--
john r pierce                                      37N 122W
somewhere on the middle of the left coast