Re: [HACKERS] SSL over Unix-domain sockets

Using the attached patch, SSL will act over Unix-domain sockets. AFAICT, this
just works. I didn't find a way to sniff a Unix-domain socket, however.

How should we proceed with this?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Fri, Jan 04, 2008 at 05:13:21PM +0100, Peter Eisentraut wrote:
> Using the attached patch, SSL will act over Unix-domain sockets. AFAICT, this
> just works. I didn't find a way to sniff a Unix-domain socket, however.

Looks clear enough. You should be able to test if it works by using
strace to check the data it's sending.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy

Peter Eisentraut wrote:
> Using the attached patch, SSL will act over Unix-domain sockets. AFAICT, this
> just works. I didn't find a way to sniff a Unix-domain socket, however.
>
> How should we proceed with this?

I am confused by the shortness of this patch. Right now pg_hba.conf
has:

# host DATABASE USER CIDR-ADDRESS METHOD [OPTION]
# hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
# hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION]

These are all for TCP connections. How do we handle 'local' SSL
connection specification? Do we want to provide similar functionality
for local connections?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Am Freitag, 4. Januar 2008 schrieb Bruce Momjian:
> Peter Eisentraut wrote:
> > Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
> > this just works. I didn't find a way to sniff a Unix-domain socket,
> > however.
> >
> > How should we proceed with this?
>
> I am confused by the shortness of this patch. Right now pg_hba.conf
> has:
>
> # host DATABASE USER CIDR-ADDRESS METHOD [OPTION]
> # hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
> # hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
>
> These are all for TCP connections. How do we handle 'local' SSL
> connection specification? Do we want to provide similar functionality
> for local connections?

Yes, we might want to add that as well. That and some documentation updates
would probably cover everything.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Am Freitag, 4. Januar 2008 schrieb Bruce Momjian:
> > Peter Eisentraut wrote:
> > > Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
> > > this just works. I didn't find a way to sniff a Unix-domain socket,
> > > however.
> > >
> > > How should we proceed with this?
> >
> > I am confused by the shortness of this patch. Right now pg_hba.conf
> > has:
> >
> > # host DATABASE USER CIDR-ADDRESS METHOD [OPTION]
> > # hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
> > # hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
> >
> > These are all for TCP connections. How do we handle 'local' SSL
> > connection specification? Do we want to provide similar functionality
> > for local connections?
>
> Yes, we might want to add that as well. That and some documentation updates
> would probably cover everything.

OK. Right now the documentation about spoofing says to use directory
permissions for the socket, and that works. I am thinking this is
something for 8.4.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> Am Freitag, 4. Januar 2008 schrieb Bruce Momjian:
>>> Peter Eisentraut wrote:
>>>> Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
>>>> this just works. I didn't find a way to sniff a Unix-domain socket,
>>>> however.
>>>>
>>>> How should we proceed with this?
>>> I am confused by the shortness of this patch. Right now pg_hba.conf
>>> has:
>>>
>>> # host DATABASE USER CIDR-ADDRESS METHOD [OPTION]
>>> # hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
>>> # hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
>>>
>>> These are all for TCP connections. How do we handle 'local' SSL
>>> connection specification? Do we want to provide similar functionality
>>> for local connections?
>> Yes, we might want to add that as well. That and some documentation updates
>> would probably cover everything.
>
> OK. Right now the documentation about spoofing says to use directory
> permissions for the socket, and that works. I am thinking this is
> something for 8.4.

Actually, if you just commit that patch *without* pg_hba modifications,
it still solves the problem stated, no? Because the client can be
configured to require ssl and to require server certificate validation,
and that's the hole we're trying to plug here...

//Magnus

Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> Am Freitag, 4. Januar 2008 schrieb Bruce Momjian:
> >>> Peter Eisentraut wrote:
> >>>> Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
> >>>> this just works. I didn't find a way to sniff a Unix-domain socket,
> >>>> however.
> >>>>
> >>>> How should we proceed with this?
> >>> I am confused by the shortness of this patch. Right now pg_hba.conf
> >>> has:
> >>>
> >>> # host DATABASE USER CIDR-ADDRESS METHOD [OPTION]
> >>> # hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
> >>> # hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
> >>>
> >>> These are all for TCP connections. How do we handle 'local' SSL
> >>> connection specification? Do we want to provide similar functionality
> >>> for local connections?
> >> Yes, we might want to add that as well. That and some documentation updates
> >> would probably cover everything.
> >
> > OK. Right now the documentation about spoofing says to use directory
> > permissions for the socket, and that works. I am thinking this is
> > something for 8.4.
>
> Actually, if you just commit that patch *without* pg_hba modifications,
> it still solves the problem stated, no? Because the client can be
> configured to require ssl and to require server certificate validation,
> and that's the hole we're trying to plug here...

Yes, it would plug the hole without fully implementing SSL control on
local sockets. However, the hole is already plugged by using directory
permissions so I question the need for a partial solution at this point
in 8.3.

At this point in 8.3 I think we have to ask if we would make such a
change in a minor release, and I don't think we would.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

* Bruce Momjian <bruce(at)momjian(dot)us> [080104 13:00]:

> > Actually, if you just commit that patch *without* pg_hba modifications,
> > it still solves the problem stated, no? Because the client can be
> > configured to require ssl and to require server certificate validation,
> > and that's the hole we're trying to plug here...
>
> Yes, it would plug the hole without fully implementing SSL control on
> local sockets. However, the hole is already plugged by using directory
> permissions so I question the need for a partial solution at this point
> in 8.3.

Yet we have respected people warning us that the *only* place we can
have the socket is /tmp, because that's where everybody (for varying
definitions of everybody) looks. Moving the socket from /tmp actually
makes the problem of a spoofed postmaster bigger.

If you have a scheme to "move" or protect the unix socket, make sure you
still provide the one in /tmp. A simple test looks like the
/tmp/.s.PGSQL.XXXX can be a symlink the socket in the protected dir, so
it may be enough for concerned admins to create this symlink (or the
actual socket with correct owner/permissions) on system startup,
preventing an "outsider" from taking this file before postgresql (and
make sure that no tmpwatch or anything removes it again).

But if PostgreSQL is started before your "untrusted user processes",
then your untrusted user processes should never get the chance to spoof
the server unless they get to mv/delete the postgres-user owned socket
in /tmp, in which case, you've got larger problems to worry about...

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Yes, it would plug the hole without fully implementing SSL control on
> local sockets. However, the hole is already plugged by using directory
> permissions so I question the need for a partial solution at this point
> in 8.3.

As already noted, "fix /tmp's directory permissions" isn't a very
helpful suggestion.

> At this point in 8.3 I think we have to ask if we would make such a
> change in a minor release, and I don't think we would.

It depends on whether you call it a new feature or a bug fix.
If it is a bug fix, wouldn't we also back-patch it?

Given the smallness of Peter's patch, I don't think that treating
it as a bug fix is unreasonable, if that (and the docs) are all we
change. Now adding "localssl" etc to pg_hba.conf's options seems
more like a new feature, and that I think should wait for 8.4.

One question is whether patching this without adding localssl
(and therefore, without providing a way for the DBA to enforce
SSL use) is actually very helpful. You could be secure but you'd
be depending on the client side to get it right. OTOH that's true
anyway if we have no way to enforce that the client verify the
postmaster's certificate.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Yes, it would plug the hole without fully implementing SSL control on
> > local sockets. However, the hole is already plugged by using directory
> > permissions so I question the need for a partial solution at this point
> > in 8.3.
>
> As already noted, "fix /tmp's directory permissions" isn't a very
> helpful suggestion.

Right, I was saying moving to a another directory, not chaning /tmp,
but you are right that some clients might still look in /tmp, and that
allows spoofing even when the postmaster is running.

> > At this point in 8.3 I think we have to ask if we would make such a
> > change in a minor release, and I don't think we would.
>
> It depends on whether you call it a new feature or a bug fix.
> If it is a bug fix, wouldn't we also back-patch it?
>
> Given the smallness of Peter's patch, I don't think that treating
> it as a bug fix is unreasonable, if that (and the docs) are all we
> change. Now adding "localssl" etc to pg_hba.conf's options seems
> more like a new feature, and that I think should wait for 8.4.
>
> One question is whether patching this without adding localssl
> (and therefore, without providing a way for the DBA to enforce
> SSL use) is actually very helpful. You could be secure but you'd
> be depending on the client side to get it right. OTOH that's true
> anyway if we have no way to enforce that the client verify the
> postmaster's certificate.

Well, if we are relying on the client we might as well tell clients to
use a new non-tmp socket location, and even with SSL we can't require
the client to check the postmaster's certificate, as you said.

If we trust the client, a new socket directory will work, but if we
don't, even SSL doesn't help us, right? SSL was used for TCP only
because it allowed trusted clients to work. We already have a unix
socket solution for trusted clients, namely a different directory.

The problem with adding SSL to local sockets is this slippery slope
where we only do part of the job, but it isn't clear where to draw the
line.

Should we wait and do the full job in 8.3.1?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Fri, Jan 04, 2008 at 02:37:03PM -0500, Bruce Momjian wrote:
> The problem with adding SSL to local sockets is this slippery slope
> where we only do part of the job, but it isn't clear where to draw the
> line.

I don't think "part of the job" for a patch is a slippery slope. It's what
you do with patches for issues discovered too late to make full release:
pick the least invasive thing you can do, release that patch, and implement
the full feature later.

A

Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
> > this just works. I didn't find a way to sniff a Unix-domain socket,
> > however.
> >
> > How should we proceed with this?
>
> I am confused by the shortness of this patch. Right now pg_hba.conf
> has:
>
> # host DATABASE USER CIDR-ADDRESS METHOD [OPTION]
> # hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
> # hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION]
>
> These are all for TCP connections. How do we handle 'local' SSL
> connection specification? Do we want to provide similar functionality
> for local connections?

Here is a patch that implements "localssl" as well. It is quite simple.
(Note that the code in hba.c is all copy and paste.)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Here is a patch that implements "localssl" as well. It is quite simple.

The other area that would need some thought before we could consider
this "done" is the behavior of libpq's sslmode parameter. With the
patch as given, an SSL-capable libpq will *default* to using SSL over
sockets, which might be thought overkill; it is almost certainly
going to result in a performance penalty. Is this a reasonable default
behavior? Should sslmode be extended to allow specification of
different behaviors for sockets vs. TCP?

regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>
>> Here is a patch that implements "localssl" as well. It is quite simple.
>>
> The other area that would need some thought before we could consider
> this "done" is the behavior of libpq's sslmode parameter. With the
> patch as given, an SSL-capable libpq will *default* to using SSL over
> sockets, which might be thought overkill; it is almost certainly
> going to result in a performance penalty. Is this a reasonable default
> behavior? Should sslmode be extended to allow specification of
> different behaviors for sockets vs. TCP
Does the patch handle patched clients connecting to unpatched servers
and vice versa?

I am undecided whether I will use this proposed functionality or not. I
would like to tighten up security (only a few people have access to the
machine, but even a few may be a few too many?). Cryptographic
authentication and encrypted data stream cost is high compared to no
cryptographic authentication or encrypted data streams. I don't know if
it would impact me or not. Peter: Have you tried running a benchmark of
localssl vs localnossl?

Cheers,
mark

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

Mark Mielke wrote:
> Does the patch handle patched clients connecting to unpatched servers
> and vice versa?

Yes, it is all compatible.

> Cryptographic
> authentication and encrypted data stream cost is high compared to no
> cryptographic authentication or encrypted data streams. I don't know if
> it would impact me or not. Peter: Have you tried running a benchmark of
> localssl vs localnossl?

Good point. I tried this

time for x in $(seq 1 1000); do
pg-install/bin/psql -c "select 1" >/dev/null
done

With ssl=off it looks about like this:

real 0m12.909s
user 0m3.712s
sys 0m3.056s

With ssl=on it looks about like this:

real 1m4.741s
user 0m26.638s
sys 0m4.328s

It has been reported that the data transmission overhead is much less than the
connection establishing overhead, which is measured here. But this is
certainly not an encouraging measurement, if we want to put this close to the
default path of use.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> It has been reported that the data transmission overhead is much less
> than the connection establishing overhead, which is measured here.
> But this is certainly not an encouraging measurement, if we want to
> put this close to the default path of use.

I did some more experiments to confirm Peter's results. My test case
for measuring connection overhead is
pgbench -c 1 -t 1000 -S -n -C bench
(ie, single client, SELECT-only transaction, connecting again for each
transaction). This is marginally more realistic than Peter's test
since the client executes a SQL command per connection. I get

$ PGSSLMODE=prefer time pgbench -c 1 -t 1000 -S -n -C bench
transaction type: SELECT only
scaling factor: 10
number of clients: 1
number of transactions per client: 1000
number of transactions actually processed: 1000/1000
tps = 33.078772 (including connections establishing)
tps = 33.078772 (excluding connections establishing)
10.45user 0.68system 0:30.26elapsed 36%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+48465minor)pagefaults 0swaps

$ PGSSLMODE=disable time pgbench -c 1 -t 1000 -S -n -C bench
transaction type: SELECT only
scaling factor: 10
number of clients: 1
number of transactions per client: 1000
number of transactions actually processed: 1000/1000
tps = 156.237184 (including connections establishing)
tps = 156.237208 (excluding connections establishing)
0.20user 0.18system 0:06.41elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2500minor)pagefaults 0swaps

$ PGSSLMODE=prefer time pgbench -c 1 -t 1000 -S -n -C -h localhost bench
transaction type: SELECT only
scaling factor: 10
number of clients: 1
number of transactions per client: 1000
number of transactions actually processed: 1000/1000
tps = 32.320773 (including connections establishing)
tps = 32.320774 (excluding connections establishing)
10.54user 1.01system 0:30.97elapsed 37%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+49807minor)pagefaults 0swaps

$ PGSSLMODE=disable time pgbench -c 1 -t 1000 -S -n -C -h localhost bench
transaction type: SELECT only
scaling factor: 10
number of clients: 1
number of transactions per client: 1000
number of transactions actually processed: 1000/1000
tps = 144.859620 (including connections establishing)
tps = 144.859641 (excluding connections establishing)
0.32user 0.62system 0:06.91elapsed 13%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+4512minor)pagefaults 0swaps

I also did some tests to measure the encryption overhead for bulk data,
in the form of pg_dumping a medium-size table (which is in fact just
the data from the regression test's tenk1 table, repeated 128 times):

[tgl(at)rh2 ~]$ PGSSLMODE=prefer time pg_dump -t foo regression | wc
2.71user 0.36system 0:25.09elapsed 12%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1093minor)pagefaults 0swaps
1280054 20480136 85863449

[tgl(at)rh2 ~]$ PGSSLMODE=disable time pg_dump -t foo regression | wc
0.64user 0.30system 0:09.63elapsed 9%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+793minor)pagefaults 0swaps
1280054 20480136 85863449

[tgl(at)rh2 ~]$ PGSSLMODE=prefer time pg_dump -t foo -h localhost regression | wc
3.06user 0.45system 0:25.82elapsed 13%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1105minor)pagefaults 0swaps
1280054 20480136 85863449

[tgl(at)rh2 ~]$ PGSSLMODE=disable time pg_dump -t foo -h localhost regression | wc
0.66user 0.42system 0:09.91elapsed 10%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+806minor)pagefaults 0swaps
1280054 20480136 85863449

Note that these times are for SSL enabled, but without any root.crt
files, so no actual authentication is happening --- I'm not sure how
much more connection-time overhead that would incur. Presumably the
bulk transfer rate wouldn't change though. All these numbers are
stable to within a percent or three over repeated trials.

Conclusions:

* SSL, even without real authentication, is *way* too expensive to
enable by default.

* The extra cost of going across a local TCP connection is measurable,
but it's insignificant compared to the cost of turning on SSL. (This
is on a Fedora 8 kernel BTW ... that result might vary on other
platforms.)

So you could make a pretty good case that the answer for DBAs who
want to prevent spoofing is to disable socket connections in pg_hba.conf
and force even local connections to come through "hostssl" connections.

If we do want to apply Peter's patch, I think it needs to be extended so
that the default behavior on sockets is the same as before, ie, no SSL.
This could be done by giving libpq an additional connection parameter,
say "socketsslmode", having the same alternatives as sslmode but
defaulting to "allow" instead of "prefer".

regards, tom lane

Tom Lane wrote:
> Conclusions:
>
> * SSL, even without real authentication, is *way* too expensive to
> enable by default.
>
> * The extra cost of going across a local TCP connection is measurable,
> but it's insignificant compared to the cost of turning on SSL. (This
> is on a Fedora 8 kernel BTW ... that result might vary on other
> platforms.)
>
> So you could make a pretty good case that the answer for DBAs who
> want to prevent spoofing is to disable socket connections in pg_hba.conf
> and force even local connections to come through "hostssl" connections.

Yea, I figured using protected directories for the socket was the
zero-cost solution, and if you have to do SSL, might as well just use
TCP too. (If you moved the socket file to a protected directory I think
you could use external_pid_file='/tmp/.s.PGSQL.5432' to prevent a spoof
socket file in /tmp. Should we document that idea?)

> If we do want to apply Peter's patch, I think it needs to be extended so
> that the default behavior on sockets is the same as before, ie, no SSL.
> This could be done by giving libpq an additional connection parameter,
> say "socketsslmode", having the same alternatives as sslmode but
> defaulting to "allow" instead of "prefer".

That seems like it is going to be added confusion; just using the
protected socket diretory or TCP & SSL seems less error-prone.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Yea, I figured using protected directories for the socket was the
> zero-cost solution, and if you have to do SSL, might as well just use
> TCP too. (If you moved the socket file to a protected directory I think
> you could use external_pid_file='/tmp/.s.PGSQL.5432' to prevent a spoof
> socket file in /tmp. Should we document that idea?)

Umm ... two questions about that:

* will the postmaster fail if there's a socket where it tries to write
the external_pid_file? (If it does fail, does that really fix
anything? The spoofer already owns the socket.)

* if there's a plain file where a client expects to find the socket,
what happens? (Probably nothing very good, since the first thing the
client will do is write on it.)

>> If we do want to apply Peter's patch, I think it needs to be extended so
>> that the default behavior on sockets is the same as before, ie, no SSL.

> That seems like it is going to be added confusion; just using the
> protected socket diretory or TCP & SSL seems less error-prone.

Yeah, all of this is about confusion and error-proneness. I still think
that the real problem is that we don't have full control over
client-side code, and therefore can't just write off the problem of a
client deciding to connect to /tmp/.s.PGSQL.5432 even if the local DBA
thinks the socket would be safer elsewhere.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Yea, I figured using protected directories for the socket was the
> > zero-cost solution, and if you have to do SSL, might as well just use
> > TCP too. (If you moved the socket file to a protected directory I think
> > you could use external_pid_file='/tmp/.s.PGSQL.5432' to prevent a spoof
> > socket file in /tmp. Should we document that idea?)
>
> Umm ... two questions about that:
>
> * will the postmaster fail if there's a socket where it tries to write
> the external_pid_file? (If it does fail, does that really fix
> anything? The spoofer already owns the socket.)

I figured it would prevent someone from spoofing while the server was
up, which is a _new_ problem when moving the socket. :-(

My feeling on the moving of sockets risk is that you are probably going
to have all your clients using the new socket directory before anyone
tries to put something in /tmp, especially if you have the lock file in
/tmp as outlined above. To spoof in such a situation you would need to
do the attack while the server is down _and_ against a client that
doesn't know the right socket location.

> * if there's a plain file where a client expects to find the socket,
> what happens? (Probably nothing very good, since the first thing the
> client will do is write on it.)

We would have to test that.

> >> If we do want to apply Peter's patch, I think it needs to be extended so
> >> that the default behavior on sockets is the same as before, ie, no SSL.
>
> > That seems like it is going to be added confusion; just using the
> > protected socket diretory or TCP & SSL seems less error-prone.
>
> Yeah, all of this is about confusion and error-proneness. I still think
> that the real problem is that we don't have full control over
> client-side code, and therefore can't just write off the problem of a
> client deciding to connect to /tmp/.s.PGSQL.5432 even if the local DBA
> thinks the socket would be safer elsewhere.

Right. I think the lock file in /tmp does help somewhat.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> Yeah, all of this is about confusion and error-proneness. I still think
>> that the real problem is that we don't have full control over
>> client-side code, and therefore can't just write off the problem of a
>> client deciding to connect to /tmp/.s.PGSQL.5432 even if the local DBA
>> thinks the socket would be safer elsewhere.

> Right. I think the lock file in /tmp does help somewhat.

Even if it happens to work (on some platforms) it seems like a kluge.

It strikes me that given the postmaster's infrastructure for listening
on multiple sockets, it would be a pretty small matter of programming
to teach it to listen on socket files in multiple directories not only
one. If we had that, the postmaster could listen in both /tmp and
your-more-secure-directory-of-choice. Surely an actual socket file
would be a more useful "blocker" in /tmp than a dead-weight PID file.

regards, tom lane

Am Montag, 14. Januar 2008 schrieb Tom Lane:
> If we do want to apply Peter's patch, I think it needs to be extended so
> that the default behavior on sockets is the same as before, ie, no SSL.
> This could be done by giving libpq an additional connection parameter,
> say "socketsslmode", having the same alternatives as sslmode but
> defaulting to "allow" instead of "prefer".

I suggest we don't do anything for 8.3, and return to investigate the full
range of options for 8.4. Those might include adding SSL support for local
sockets but disabled by default, using SO_PEERCRED to check the server
identity, and more fine-grained control over (multiple?) local socket
placement.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Tue, Jan 15, 2008 at 10:10:37AM +0100, Peter Eisentraut wrote:
> Am Montag, 14. Januar 2008 schrieb Tom Lane:
> > If we do want to apply Peter's patch, I think it needs to be extended so
> > that the default behavior on sockets is the same as before, ie, no SSL.
> > This could be done by giving libpq an additional connection parameter,
> > say "socketsslmode", having the same alternatives as sslmode but
> > defaulting to "allow" instead of "prefer".
>
> I suggest we don't do anything for 8.3, and return to investigate the full
> range of options for 8.4. Those might include adding SSL support for local
> sockets but disabled by default, using SO_PEERCRED to check the server
> identity, and more fine-grained control over (multiple?) local socket
> placement.

+1

//Magnus

Bruce Momjian wrote:

> My feeling on the moving of sockets risk is that you are probably going
> to have all your clients using the new socket directory before anyone
> tries to put something in /tmp, especially if you have the lock file in
> /tmp as outlined above. To spoof in such a situation you would need to
> do the attack while the server is down _and_ against a client that
> doesn't know the right socket location.

Perhaps the easiest thing to do is to create a (possibly dangling)
symlink in /tmp to the real socket in a protected dir. This symlink
would be created at start time by an early init script and never
deleted.

So when postmaster is down, the symlink is dangling but it cannot be
overwritten by the attacker. And when postmaster is running, the client
can find the true socket via either path.

One thing to be aware of is /tmp cleaners ...

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Tom Lane wrote:

> It strikes me that given the postmaster's infrastructure for listening
> on multiple sockets, it would be a pretty small matter of programming
> to teach it to listen on socket files in multiple directories not only
> one.

The problem with this idea is that if the postmaster goes away, both
sockets go away, which means the attacker can place his socket in /tmp
as he sees fit.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

* Alvaro Herrera <alvherre(at)commandprompt(dot)com> [080115 07:24]:
> Tom Lane wrote:
>
> > It strikes me that given the postmaster's infrastructure for listening
> > on multiple sockets, it would be a pretty small matter of programming
> > to teach it to listen on socket files in multiple directories not only
> > one.
>
> The problem with this idea is that if the postmaster goes away, both
> sockets go away, which means the attacker can place his socket in /tmp
> as he sees fit.

So, make your postmaster listen in a secure location (i.e.
/var/run/postgresl/.s.PGSQL.5432), and have some init script that runs
*before* your attacker put a symlink in /tmp/s.PGSQL.5432 pointing to
it. This "init" script could even be the normal system postgres init
script.

As long as your symlink is made before your attacker get's a chance to
run anything, your attacker can't change/replace it (or you have more
serious problems), and your "safe" location is protected while you've
stopped the postmaster by normal unix permisions.

I don't think we need to go off trying to build anything new. A little
bit of documentation mentioning that creating/removing the socket from
/tmp can lead to a possible spoofed situation is all you need. Normal
unix permissions can solve the problem completely.

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

On Mon, Jan 14, 2008 at 10:24:06PM -0500, Bruce Momjian wrote:
> Yea, I figured using protected directories for the socket was the
> zero-cost solution, and if you have to do SSL, might as well just use
> TCP too. (If you moved the socket file to a protected directory I think
> you could use external_pid_file='/tmp/.s.PGSQL.5432' to prevent a spoof
> socket file in /tmp. Should we document that idea?)

Just for reference: who is it we're worried will check the old
location? Any client using libpq will use the protected directory
built into that. And JDBC is using TCP anyway because it doesn't
support Unix domain. Which seems like a very small minority of possible
clients.

Unless people are specifying (unnecessarily) /tmp directly in the
connection string? Is that common? Perhaps we should discourage that.

BTW, setting up a normal file in /tmp instead of a socket is OK, sockets
are connected to, not opened. Trying to open it normally produces the
error: No such device or address.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> Yeah, all of this is about confusion and error-proneness. I still think
> >> that the real problem is that we don't have full control over
> >> client-side code, and therefore can't just write off the problem of a
> >> client deciding to connect to /tmp/.s.PGSQL.5432 even if the local DBA
> >> thinks the socket would be safer elsewhere.
>
> > Right. I think the lock file in /tmp does help somewhat.
>
> Even if it happens to work (on some platforms) it seems like a kluge.
>
> It strikes me that given the postmaster's infrastructure for listening
> on multiple sockets, it would be a pretty small matter of programming
> to teach it to listen on socket files in multiple directories not only
> one. If we had that, the postmaster could listen in both /tmp and
> your-more-secure-directory-of-choice. Surely an actual socket file
> would be a more useful "blocker" in /tmp than a dead-weight PID file.

The problem with creating a working second socket in /tmp is that the
client would succeed with the insecure socket location and when the
server is down spoofing is possible. I figure the client should fail so
users know the client is incorrectly/insecurely configured.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Perhaps the easiest thing to do is to create a (possibly dangling)
> symlink in /tmp to the real socket in a protected dir.

Cute idea ...

> One thing to be aware of is /tmp cleaners ...

... but that would definitely be a problem. I think on most systems
you'd have to explicitly tweak the /tmp-cleaning script to know not to
zap such a link. Given that such a local customization would probably
disappear in your next system update, the security gain might be
fleeting.

regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:

> > One thing to be aware of is /tmp cleaners ...
>
> ... but that would definitely be a problem. I think on most systems
> you'd have to explicitly tweak the /tmp-cleaning script to know not to
> zap such a link. Given that such a local customization would probably
> disappear in your next system update, the security gain might be
> fleeting.

We could hack the postmaster so that it touches the /tmp socket
(hardcoded path) in addition to the unix_socket_directory one.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> Just for reference: who is it we're worried will check the old
> location? Any client using libpq will use the protected directory
> built into that.

Only if it's using the same copy of libpq that was built with the
server. Also, there are non-libpq-based client implementations out
there, or at least used to be.

regards, tom lane

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>>> One thing to be aware of is /tmp cleaners ...
>>
>> ... but that would definitely be a problem. I think on most systems
>> you'd have to explicitly tweak the /tmp-cleaning script to know not to
>> zap such a link. Given that such a local customization would probably
>> disappear in your next system update, the security gain might be
>> fleeting.

> We could hack the postmaster so that it touches the /tmp socket
> (hardcoded path) in addition to the unix_socket_directory one.

That only saves you if the postmaster is running all the time;
which was an objection already made to several other schemes ...

regards, tom lane

>>> On Mon, Jan 14, 2008 at 9:33 PM, in message <11967(dot)1200368008(at)sss(dot)pgh(dot)pa(dot)us>,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Yeah, all of this is about confusion and error-proneness. I still think
> that the real problem is that we don't have full control over
> client-side code, and therefore can't just write off the problem of a
> client deciding to connect to /tmp/.s.PGSQL.5432 even if the local DBA
> thinks the socket would be safer elsewhere.

The local DBA may have sufficient control over client-side code.

There probably are use cases where using a secure directory isn't a
complete solution; but for us, the spoofing in /tmp is a real risk
and using a secure directory solves the problem just fine.

Are we sure there really are users who need the other options?

-Kevin

On Tue, 15 Jan 2008, Tom Lane wrote:

> I think on most systems you'd have to explicitly tweak the /tmp-cleaning
> script to know not to zap such a link. Given that such a local
> customization would probably disappear in your next system update, the
> security gain might be fleeting.

Right, on the RedHat box I have handy you'd have to edit
/etc/cron.daily/tmpwatch and add "-x s.PGSQL.5432" to the first line
there. I don't think that file changes very often because of routine
updates anyway, and even if it did you wouldn't lose your custom version.
That's listed as a config file, not a binary, so the revised one would
show up as tmpwatch.rpmnew and it would be your job to reconcile the
packager's changes. People who just let the GUI updater loose might not
notice that though.

Other types of systems will obviously have their own ways to cope with
such local customization. In the short-term, you're already exposed to
the problem when walking down this road because of the edit to the startup
script that creates the symlink in the first place. For some people
that's also a tweak to a script that could be updated in a conflicting
way.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Bruce Momjian wrote:
> Tom Lane wrote:
> > Conclusions:
> >
> > * SSL, even without real authentication, is *way* too expensive to
> > enable by default.
> >
> > * The extra cost of going across a local TCP connection is measurable,
> > but it's insignificant compared to the cost of turning on SSL. (This
> > is on a Fedora 8 kernel BTW ... that result might vary on other
> > platforms.)
> >
> > So you could make a pretty good case that the answer for DBAs who
> > want to prevent spoofing is to disable socket connections in pg_hba.conf
> > and force even local connections to come through "hostssl" connections.
>
> Yea, I figured using protected directories for the socket was the
> zero-cost solution, and if you have to do SSL, might as well just use
> TCP too. (If you moved the socket file to a protected directory I think
> you could use external_pid_file='/tmp/.s.PGSQL.5432' to prevent a spoof
> socket file in /tmp. Should we document that idea?)

I did some research on this. external_pid_file will not prevent the
server from starting. If the lock file exists it just generates an
entry in the log file:

postmaster: could not write external PID file "/tmp/x": Permission denied

Looking at the threat matrix, we have:

Server Client Server Up? Spoofable?
/tmp /tmp Y N
/tmp /tmp N Y
$HOME $HOME Y N
$HOME $HOME N N
$HOME /tmp Y N
$HOME /tmp N Y

Basically, if you use a user-specific directory for the server socket
file ($HOME) and an external_pid_file, the only way for the client to be
spoofed is for the client to be using /tmp _and_ for the server to be
down.

I assume most new applications will be tested while the server is up and
therefore will fail and the client will be fixed.

I have written the following documentation addition suggesting the use
of external_pid_file.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> I have written the following documentation addition suggesting the use
> of external_pid_file.

How does that prevent spoofing?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Perhaps the easiest thing to do is to create a (possibly dangling)
> > symlink in /tmp to the real socket in a protected dir.
>
> Cute idea ...
>
> > One thing to be aware of is /tmp cleaners ...
>
> ... but that would definitely be a problem. I think on most systems
> you'd have to explicitly tweak the /tmp-cleaning script to know not to
> zap such a link. Given that such a local customization would probably
> disappear in your next system update, the security gain might be
> fleeting.

Ok, I checked on my system and if I upgrade the /tmp cleaner
(tmpreaper), my customization to the config file is not lost.

Somebody else said elsewhere that if you configure tmpwatch on Redhat
and later upgrade it, the config change is not lost.

That's two popular platforms on which this is a surmountable problem.

So my suggestion is to document this threat, the dangling-symlink
approach, and the need to configure the system's /tmp-cleaner.
Additionally, we can patch the postmaster so that it throws a WARNING if
it finds that the /tmp symlink (when configured to put the socket
somewhere else) is not present.

BTW I noticed that tmpreaper is disabled even after installed,
mentioning a security flaw which is said to be impossible to close --
and points to
http://lists.openwall.net/full-disclosure/2002/12/20/19

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > I have written the following documentation addition suggesting the use
> > of external_pid_file.
>
> How does that prevent spoofing?

It creates a lock file that is the same name as the socket file that a
default-configured client would use, so it prevents a spoofed socket
from being created.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Peter Eisentraut wrote:
>> How does that prevent spoofing?

> It creates a lock file that is the same name as the socket file that a
> default-configured client would use, so it prevents a spoofed socket
> from being created.

Only if the attacker didn't get there first. I think this idea is
nothing but a crude kluge anyway...

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>
>> Peter Eisentraut wrote:
>>
>>> How does that prevent spoofing?
>>>
>
>
>> It creates a lock file that is the same name as the socket file that a
>> default-configured client would use, so it prevents a spoofed socket
>> from being created.
>>
>
> Only if the attacker didn't get there first. I think this idea is
> nothing but a crude kluge anyway...
>
>

I agree. I remain of the opinion that this is not a problem than can be
solved purely within the bounds of postgres.

cheers

andrew

Andrew Dunstan wrote:

> I agree. I remain of the opinion that this is not a problem than can be
> solved purely within the bounds of postgres.

I agree. Please comment on my proposed solution.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>
>> I agree. I remain of the opinion that this is not a problem than can be
>> solved purely within the bounds of postgres.
>>
>
> I agree. Please comment on my proposed solution.
>
>

I'm not sure tmp cleaners will work that well against a determined spoofer.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Alvaro Herrera wrote:
>> Andrew Dunstan wrote:
>>
>>
>>> I agree. I remain of the opinion that this is not a problem than can be
>>> solved purely within the bounds of postgres.
>>
>> I agree. Please comment on my proposed solution.
>
> I'm not sure tmp cleaners will work that well against a determined spoofer.

I don't understand. The tmp cleaner is something we have to _avoid_.
Let me repeat my proposal.

I propose to create a dangling symlink on system startup in
/tmp/.s.PGSQL.<port> to the real socket, which is not on a
world-writable directory. This avoids the spoofer, because he cannot
create the socket -- the symlink is occupying its place.

The only problem with this proposal is that the tmp cleaner would remove
the symlink. The solution to this is to configure the tmp cleaner so
that it doesn't do that.

It absolutely requires cooperation from the sysadmin, both to setup the
symlink initially, and to configure the tmp cleaner.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> I propose to create a dangling symlink on system startup in
> /tmp/.s.PGSQL.<port> to the real socket, which is not on a
> world-writable directory. This avoids the spoofer, because he cannot
> create the socket -- the symlink is occupying its place.

> The only problem with this proposal is that the tmp cleaner would remove
> the symlink. The solution to this is to configure the tmp cleaner so
> that it doesn't do that.

> It absolutely requires cooperation from the sysadmin, both to setup the
> symlink initially, and to configure the tmp cleaner.

This is definitely a slick solution if you can overcome the tmp-cleaner
risk; not least because it doesn't require any work on our part ;-).
However, we should document the approach someplace.

Further down the road we could think about Postgres changes to support
such a strategy --- for instance, having the postmaster check to see
if such a link exists. This will require more thought than we have
time for for 8.3; also I think we'd need to negotiate with packagers,
such as the Debian crew, to make sure any such behavior is acceptable
to them.

BTW, is a symlink's atime changed by accessing it? We could imagine
adapting the existing postmaster code that keeps the socket atime fresh
so that it will work on a symlink, thus providing partial protection
against tmp-cleaners. Portability of this is uncertain...

regards, tom lane

Alvaro Herrera wrote:
> > I'm not sure tmp cleaners will work that well against a determined spoofer.
>
> I don't understand. The tmp cleaner is something we have to _avoid_.
> Let me repeat my proposal.
>
> I propose to create a dangling symlink on system startup in
> /tmp/.s.PGSQL.<port> to the real socket, which is not on a

I am confused because you say "dangling" then you say "to the real
socket". You are saying it isn't dangling when the server is running?

> world-writable directory. This avoids the spoofer, because he cannot
> create the socket -- the symlink is occupying its place.
>
> The only problem with this proposal is that the tmp cleaner would remove
> the symlink. The solution to this is to configure the tmp cleaner so
> that it doesn't do that.
>
> It absolutely requires cooperation from the sysadmin, both to setup the
> symlink initially, and to configure the tmp cleaner.

If you are going to require the admin to modify the tmp cleanup script,
the admin might as well create the symlink at the same time and have it
recreate on boot. We could actually just document this idea and be done
with it.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > > I'm not sure tmp cleaners will work that well against a determined spoofer.
> >
> > I don't understand. The tmp cleaner is something we have to _avoid_.
> > Let me repeat my proposal.
> >
> > I propose to create a dangling symlink on system startup in
> > /tmp/.s.PGSQL.<port> to the real socket, which is not on a
>
> I am confused because you say "dangling" then you say "to the real
> socket". You are saying it isn't dangling when the server is running?
>
> > world-writable directory. This avoids the spoofer, because he cannot
> > create the socket -- the symlink is occupying its place.
> >
> > The only problem with this proposal is that the tmp cleaner would remove
> > the symlink. The solution to this is to configure the tmp cleaner so
> > that it doesn't do that.
> >
> > It absolutely requires cooperation from the sysadmin, both to setup the
> > symlink initially, and to configure the tmp cleaner.
>
> If you are going to require the admin to modify the tmp cleanup script,
> the admin might as well create the symlink at the same time and have it
> recreate on boot. We could actually just document this idea and be done
> with it.

Oh, sorry, I see now you are having the admin create the symlink and
modify the tmp cleaner --- yea, I think we just document this and call
it done.

Do we do anything in the backend for this proposal?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> I am confused because you say "dangling" then you say "to the real
> socket". You are saying it isn't dangling when the server is running?

Exactly. When the server is running it provides a perfectly good path
to the postmaster. The point (and the main difference from your PIDfile
proposal) is that it's supposed to be there all the time, even when the
postmaster isn't running. This is what provides protection against the
spoofer getting there first.

> If you are going to require the admin to modify the tmp cleanup script,
> the admin might as well create the symlink at the same time and have it
> recreate on boot.

No, that's not the same, because it doesn't provide protection against
the symlink getting deleted later on.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > I am confused because you say "dangling" then you say "to the real
> > socket". You are saying it isn't dangling when the server is running?
>
> Exactly. When the server is running it provides a perfectly good path
> to the postmaster. The point (and the main difference from your PIDfile
> proposal) is that it's supposed to be there all the time, even when the
> postmaster isn't running. This is what provides protection against the
> spoofer getting there first.

OK, got it.

> > If you are going to require the admin to modify the tmp cleanup script,
> > the admin might as well create the symlink at the same time and have it
> > recreate on boot.
>
> No, that's not the same, because it doesn't provide protection against
> the symlink getting deleted later on.

Right, so you have to modify the tmp cleaner and create the symlink, right?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>> Alvaro Herrera wrote:
>>
>>> Andrew Dunstan wrote:
>>>
>>>
>>>
>>>> I agree. I remain of the opinion that this is not a problem than can be
>>>> solved purely within the bounds of postgres.
>>>>
>>> I agree. Please comment on my proposed solution.
>>>
>> I'm not sure tmp cleaners will work that well against a determined spoofer.
>>
>
> I don't understand. The tmp cleaner is something we have to _avoid_.
> Let me repeat my proposal.
>
> I propose to create a dangling symlink on system startup in
> /tmp/.s.PGSQL.<port> to the real socket, which is not on a
> world-writable directory. This avoids the spoofer, because he cannot
> create the socket -- the symlink is occupying its place.
>
> The only problem with this proposal is that the tmp cleaner would remove
> the symlink. The solution to this is to configure the tmp cleaner so
> that it doesn't do that.
>
> It absolutely requires cooperation from the sysadmin, both to setup the
> symlink initially, and to configure the tmp cleaner.
>

Oh. I'm sorry. Yes, I think this would work.

cheers

andrew

On Thu, 17 Jan 2008, Tom Lane wrote:

> BTW, is a symlink's atime changed by accessing it?

It seems so in the cases I've tried or researched, but it's complicated.
After burning through a bunch of time looking into this I wanted to drop
some notes so nobody else has to wander down the specific dead-ends I just
followed.

I figured I'd just run some experiments to figure this out for my Linux
system, but that didn't go so well. The process of running anything that
shows the atime:

ls -l --time=atime <file>
ls -lu <file>
stat <file>

actually updates the atime to right now along the way. I hacked up
something with perl that directly calls lstat() and it did the same thing.

Mystified, I found this thread suggesting the same thing is true on Mac OS
X: http://lists.apple.com/archives/darwin-kernel/2006/Dec/msg00054.html

The point made in there is that how symlinks are encoded varies not just
from OS to OS but from filesystem to filesystem, and that encoding changes
how things like atime work. On Linux with ext2, I found this note:

"Symbolic links are also filesystem objects with inodes. They deserve
special mention because the data for them is stored within the inode
itself if the symlink is less than 60 bytes long. It uses the fields
which would normally be used to store the pointers to data blocks."

So what I think is happening is: the process of doing anything at all
with a Linux symlink references the inode that has the link. That updates
the atime on that inode. But since there's no actual data underneath that
lookup in cases where the link is less than 60 bytes, the inode atime is
the link atime, so that just updated the link's atime to right now as
well. I have no idea how any tmp cleaner could ever find a short symlink
it can delete if I'm understanding this correctly.

I left behind the link I was just playing with and I'll see if I can get
tmpwatch to eat it tomorrow, that seems like the most appropriate test
here.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Am Donnerstag, 17. Januar 2008 schrieb Bruce Momjian:
> It creates a lock file that is the same name as the socket file that a
> default-configured client would use, so it prevents a spoofed socket
> from being created.

A counter-spoofing solution must be implemented in the client. No moving
around of files by the server will ever solve the problem.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Am Donnerstag, 17. Januar 2008 schrieb Andrew Dunstan:
> I agree. I remain of the opinion that this is not a problem than can be
> solved purely within the bounds of postgres.

Well, the SSL patch I showed certainly solves the problem. (I am not saying
it is the best possible solution.) Of course there also need to be prudent
users, but that is the case for any security system.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Am Freitag, 18. Januar 2008 schrieb Alvaro Herrera:
> I propose to create a dangling symlink on system startup in
> /tmp/.s.PGSQL.<port> to the real socket, which is not on a
> world-writable directory.  This avoids the spoofer, because he cannot
> create the socket -- the symlink is occupying its place.

This approaches the issue from the wrong end. Spoofing attacks the client, so
the defense must be in the client. If the defense of the client is to rely
on a carefully configured server, then that might exclude some possible
attack vectors, but it is not a defense the client can rely on.

To look at this in another way, if we relied on every browser user to type in
web addresses correctly and all server administrators to make sure
their "socket address" cannot be hijacked, we wouldn't need SSL on the web.
The proper approach, however, is to configure the client to only talk to
servers that can prove their identity.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Fri, Jan 18, 2008 at 11:24:09AM +0100, Peter Eisentraut wrote:
> Am Donnerstag, 17. Januar 2008 schrieb Andrew Dunstan:
> > I agree. I remain of the opinion that this is not a problem than can be
> > solved purely within the bounds of postgres.
>
> Well, the SSL patch I showed certainly solves the problem. (I am not saying
> it is the best possible solution.) Of course there also need to be prudent
> users, but that is the case for any security system.

Not that much more than moving the socket file to a secure directory. Both
rely on configuring the client properly. It's arguably a lot easier to
configure the client to connect to the correct socket, than to make sure
the client has a root certificate installed.

//Magnus

Am Freitag, 18. Januar 2008 schrieb Magnus Hagander:
> Not that much more than moving the socket file to a secure directory. Both
> rely on configuring the client properly. It's arguably a lot easier to
> configure the client to connect to the correct socket, than to make sure
> the client has a root certificate installed.

How would a client check whether the socket file is in a secure location?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Fri, Jan 18, 2008 at 12:35:40PM +0100, Peter Eisentraut wrote:
> Am Freitag, 18. Januar 2008 schrieb Magnus Hagander:
> > Not that much more than moving the socket file to a secure directory. Both
> > rely on configuring the client properly. It's arguably a lot easier to
> > configure the client to connect to the correct socket, than to make sure
> > the client has a root certificate installed.
>
> How would a client check whether the socket file is in a secure location?

The same way it would get the root certificate to trust - it would be told
so by the administrator who had secured the location.

//Magnus

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > I am confused because you say "dangling" then you say "to the real
> > socket". You are saying it isn't dangling when the server is running?
>
> Exactly. When the server is running it provides a perfectly good path
> to the postmaster. The point (and the main difference from your PIDfile
> proposal) is that it's supposed to be there all the time, even when the
> postmaster isn't running. This is what provides protection against the
> spoofer getting there first.

OK, I have added documention suggesting the creation a symbolic link in
/tmp to prevent server spoofing when the socket file has been moved.

I think we can consider this issue concluded. I think SSL over unix
domain sockets has so much overhead as to be worse in most cases than
just creating the symlink.

Of course if someone comes up with a better idea we can reopen this.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +