Localhost vs. Unix Domain Sockets?

Discussion:

Ken Tanzer

2014-08-18 23:55:28 UTC

Hi. I'm working with a couple of machines that have Postgres/Apache on
Linux setups. Connections to Postgres are currntly TCP/IP to localhost.
(We're also using itk, so that the apache connections are per-user.) We
began looking into about encrypting these connections with SSL, but now I'm
thinking of using unix domain socket connections instead.

I see two possible benefits to this:

1) Maybe better performance or use of resources. I didn't find a lot of
info, although this post from Bruce Momjian indicates that is is the case:
http://momjian.us/main/blogs/pgblog/2012.html#June_6_2012.

2) Our webapp and users wouldn't need to be given a Postgres password at
all. Authenticating as their user would be sufficient.

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!

Thanks in advance,

Ken
--
AGENCY Software
A Free Software data system
By and for non-profits
*http://agency-software.org/ <http://agency-software.org/>*
*https://agency-software.org/demo/client
<https://agency-software.org/demo/client>*
***@agency-software.org
(253) 245-3801

Subscribe to the mailing list
<agency-general-***@lists.sourceforge.net?body=subscribe> to
learn more about AGENCY or
follow the discussion.

John R Pierce

2014-08-19 00:00:36 UTC

Permalink

Post by Ken Tanzer
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

--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Tom Lane

2014-08-19 00:09:13 UTC

Permalink

Post by John R Pierce

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.

Post by John R Pierce
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

--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Matt S

2014-08-19 00:12:34 UTC

Permalink

I went through the same process a little while ago - worth reading is the
pg_hba.conf documentation:
http://www.postgresql.org/docs/9.1/static/auth-pg-hba-conf.html

Specifically:

* Don't enable "trust" auth (i.e. any OS user as any DB user) - that's
rarely what you want on a multi-user machine.
* "peer" auth (OS user == DB user name) is typically the way to go in most
cases - you can lock down the DB user further with GRANT privileges as
required.
* Maps (http://www.postgresql.org/docs/9.1/static/auth-username-maps.html)
are useful if you want to allow multiple OS users access to a single DB
user, or if your OS usernames are detached from your DB user names.

I use a peer map=X configuration where my application user(s) (which my app
binaries run under) are mapped to DB user names. Those DB users have
CONNECT privs on their own DBs (only).

Post by John R Pierce

Post by Ken Tanzer
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
--
http://www.postgresql.org/mailpref/pgsql-general

Ken Tanzer

2014-08-19 00:45:10 UTC

Permalink

Thanks all for the input. Sounds like there aren't downsides to sockets,
and they are at least as secure. I do have on follow-up question though:

* "peer" auth (OS user == DB user name) is typically the way to go in

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?

Cheers,
Ken
--
AGENCY Software
A Free Software data system
By and for non-profits
*http://agency-software.org/ <http://agency-software.org/>*
*https://agency-software.org/demo/client
<https://agency-software.org/demo/client>*
***@agency-software.org
(253) 245-3801

Subscribe to the mailing list
<agency-general-***@lists.sourceforge.net?body=subscribe> to
learn more about AGENCY or
follow the discussion.

John R Pierce

2014-08-19 00:54:44 UTC

Permalink

Post by Ken Tanzer
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

--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Ken Tanzer

2014-08-19 01:45:47 UTC

Permalink

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_?

To put it another way, keeping the two sets of names distinct is
incrementally more complex to manage. Which might be worth it if there
really is any gain. Is this a "best practice," or is it really a
manifestation of its closely-related cousin, the "silly practice?" :)

Cheers,
Ken
--
AGENCY Software
A Free Software data system
By and for non-profits
*http://agency-software.org/ <http://agency-software.org/>*
*https://agency-software.org/demo/client
<https://agency-software.org/demo/client>*
***@agency-software.org
(253) 245-3801

Subscribe to the mailing list
<agency-general-***@lists.sourceforge.net?body=subscribe> to
learn more about AGENCY or
follow the discussion.

John R Pierce

2014-08-19 01:51:46 UTC

Permalink

Post by Ken Tanzer
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

--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Matt S

2014-08-19 01:58:44 UTC

Permalink

Post by Ken Tanzer
To put it another way, keeping the two sets of names distinct is

incrementally more complex to manage. Which might be worth it if there
really is any gain. Is this a "best practice," or is it really a
manifestation of its closely-related cousin, the "silly practice?" :)

It's ultimately up to your use case. I generate my auth maps using CM tools
(i.e. Ansible) so the management overhead is minimal. My web applications
all run as the "deploy" (OS) user, but each have separate DB users
("baltar", "caprica", "leoben", etc.) and those DB users only have access
on the DBs they need to.

Post by Ken Tanzer
From a security perspective, any application compromise (say, a bug in an

SQL driver/lib) will therefore only affect the databases that user can
access, and not all the databases the OS user can access (which could be
many!).

Post by Ken Tanzer

Post by Ken Tanzer
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_?