Re: [HACKERS] SSL over Unix-domain sockets
On Wednesday 01 April 2009 20:37:56 Martijn van Oosterhout wrote: On Tue, Mar 31, 2009 at 11:33:26PM +0300, Peter Eisentraut wrote: On Saturday 28 March 2009 00:42:28 Bruce Momjian wrote: I assume directory permissions controlling access to the socket file would be enough. You are going to have to set up SSL certificates anyway for this so isn't that just as hard as telling the client where the socket file is located? The permissions on the socket file or the containing directory doesn't tell much by itself, because you also need to consider who owns it. What that basically comes down to is that the client would need to specify something like, I only want a connection to a server owned by 'postgres'. But the client currently has no way of saying that, so we'd need to invent something new. If you're going to get complicated, go the whole way do SO_PEERCRED on the socket, then you get the UID of the server... I have added this to the Todo list. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
On Tue, Mar 31, 2009 at 11:33:26PM +0300, Peter Eisentraut wrote: On Saturday 28 March 2009 00:42:28 Bruce Momjian wrote: I assume directory permissions controlling access to the socket file would be enough. You are going to have to set up SSL certificates anyway for this so isn't that just as hard as telling the client where the socket file is located? The permissions on the socket file or the containing directory doesn't tell much by itself, because you also need to consider who owns it. What that basically comes down to is that the client would need to specify something like, I only want a connection to a server owned by 'postgres'. But the client currently has no way of saying that, so we'd need to invent something new. If you're going to get complicated, go the whole way do SO_PEERCRED on the socket, then you get the UID of the server... Have a nice day, -- Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] SSL over Unix-domain sockets
On Saturday 28 March 2009 00:42:28 Bruce Momjian wrote: I assume directory permissions controlling access to the socket file would be enough. You are going to have to set up SSL certificates anyway for this so isn't that just as hard as telling the client where the socket file is located? The permissions on the socket file or the containing directory doesn't tell much by itself, because you also need to consider who owns it. What that basically comes down to is that the client would need to specify something like, I only want a connection to a server owned by 'postgres'. But the client currently has no way of saying that, so we'd need to invent something new. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: I thought the logical solution to this was to place the socket in a secure directory and not bother with SSL at all. How would a client algorithmically determine whether the server socket was in a secure directory? You have to configure your client to know that, but don't you need to configure your client for SSL too? Yes, but how exactly would a client know? How is a secure directory defined, in terms of C library calls, say? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Magnus Hagander wrote: Perhaps it's enough to add a localssl row to pg_hba.conf? That defeats the point, I think. You don't want the server to determine whether the client should verify the server. Good point. OTOH, client behavior can be controlled now fine by setting it to require or prefer - I think that's enough. However, we might want a simple ssl_local=true/false parameter on the server that turns it on/off completely. But the choice is that of the client: 1) I want a connection with server authentication. or 2) I want a fast connection, I don't care about server authentication. No configuration knob in the server can ever solve this. Of course the client has all the sslmode parameters to make its wishes known, but the point here is that the *default* should possibly be a different one in the case of Unix-domain sockets. Yeah, the problem is that there is only one server certificate. Is it possible/does it make sense to add an additional cn to the certificate? Yes on both. Except the current version of libpq doesn't support this :-( I was planning to add it (and still do), but the way to do it appears to be fairly complex and completely undocumented. I did some searching to find examples of it, but never followed through. After further thought, this is probably not the right solution anyway. The security of all this depends on the fact that each common name only exists once within the scope of a CA. The socket name or directory, however, is more or less them same for everyone. Another thought I had is to somehow employ hostaddr, as in hostaddr=/tmp host=real.hostname.lan. That seems rather abusive. True, but Kerberos more or less works this way. hostaddr is where to connect, host is what to use for authentication. Another^2 thought is to just examine the certificate for the local host name, which the client can find out itself. That could work. In which case we should probably consider doing the same thing for localhost or 127.0.0.1 connections. Hmm, as per my statement above, this would be the right thing to do. But I think https works differently. Tricky ... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Peter Eisentraut wrote: Magnus Hagander wrote: Perhaps it's enough to add a localssl row to pg_hba.conf? That defeats the point, I think. You don't want the server to determine whether the client should verify the server. Good point. OTOH, client behavior can be controlled now fine by setting it to require or prefer - I think that's enough. However, we might want a simple ssl_local=true/false parameter on the server that turns it on/off completely. But the choice is that of the client: 1) I want a connection with server authentication. or 2) I want a fast connection, I don't care about server authentication. No configuration knob in the server can ever solve this. Of course the client has all the sslmode parameters to make its wishes known, but the point here is that the *default* should possibly be a different one in the case of Unix-domain sockets. Agreed, except I really don't see why the default should be different. Another thought I had is to somehow employ hostaddr, as in hostaddr=/tmp host=real.hostname.lan. That seems rather abusive. True, but Kerberos more or less works this way. hostaddr is where to connect, host is what to use for authentication. Yeah, and it has always annoyed me :) I think it'd be better to just gtet the hostname of the system, and use that. Another^2 thought is to just examine the certificate for the local host name, which the client can find out itself. That could work. In which case we should probably consider doing the same thing for localhost or 127.0.0.1 connections. Hmm, as per my statement above, this would be the right thing to do. But I think https works differently. Tricky ... Yeah, https requires the cert to be named localhost. It's a smaller issue on a Unix system since the http/https ports require root to bind to them, and if somebody is root no amount of SSL is going to help you anyway... //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Regarding using the hostname of the system... There's no such thing. Interfaces have names, hosts can have multiple interfaces so the can have multiple names... I haven't follwes the discussion so I'm not sure if you have an existing connection. If so you can get the local interface address from the connection and look up the name for that address. But that only works if you already have a socket. -- Greg On 27 Mar 2009, at 07:49, Magnus Hagander mag...@hagander.net wrote: Peter Eisentraut wrote: Magnus Hagander wrote: Perhaps it's enough to add a localssl row to pg_hba.conf? That defeats the point, I think. You don't want the server to determine whether the client should verify the server. Good point. OTOH, client behavior can be controlled now fine by setting it to require or prefer - I think that's enough. However, we might want a simple ssl_local=true/false parameter on the server that turns it on/off completely. But the choice is that of the client: 1) I want a connection with server authentication. or 2) I want a fast connection, I don't care about server authentication. No configuration knob in the server can ever solve this. Of course the client has all the sslmode parameters to make its wishes known, but the point here is that the *default* should possibly be a different one in the case of Unix-domain sockets. Agreed, except I really don't see why the default should be different. Another thought I had is to somehow employ hostaddr, as in hostaddr=/tmp host=real.hostname.lan. That seems rather abusive. True, but Kerberos more or less works this way. hostaddr is where to connect, host is what to use for authentication. Yeah, and it has always annoyed me :) I think it'd be better to just gtet the hostname of the system, and use that. Another^2 thought is to just examine the certificate for the local host name, which the client can find out itself. That could work. In which case we should probably consider doing the same thing for localhost or 127.0.0.1 connections. Hmm, as per my statement above, this would be the right thing to do. But I think https works differently. Tricky ... Yeah, https requires the cert to be named localhost. It's a smaller issue on a Unix system since the http/https ports require root to bind to them, and if somebody is root no amount of SSL is going to help you anyway... //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
On Friday 27 March 2009 14:46:32 Greg Stark wrote: Regarding using the hostname of the system... There's no such thing. Interfaces have names, hosts can have multiple interfaces so the can have multiple names... But there is `hostname` and `hostname --fqdn`, both of which are well-defined independent of a connection. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
On Fri, Mar 27, 2009 at 9:47 AM, Peter Eisentraut pete...@gmx.net wrote: On Friday 27 March 2009 14:46:32 Greg Stark wrote: Regarding using the hostname of the system... There's no such thing. Interfaces have names, hosts can have multiple interfaces so the can have multiple names... But there is `hostname` and `hostname --fqdn`, both of which are well-defined independent of a connection. But they aren't guaranteed to return anything useful, and IME often don't. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Robert Haas robertmh...@gmail.com writes: On Fri, Mar 27, 2009 at 9:47 AM, Peter Eisentraut pete...@gmx.net wrote: But there is `hostname` and `hostname --fqdn`, both of which are well-defined independent of a connection. But they aren't guaranteed to return anything useful, and IME often don't. I think well defined is stretching it anyway. I see different behaviors (partially or fully qualified hostname) on my different Unix machines. --fqdn appears particularly useless, as Fedora 10 reports this: $ hostname --fqdn localhost.localdomain and my other machines don't recognize the switch at all. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Peter Eisentraut wrote: Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: I thought the logical solution to this was to place the socket in a secure directory and not bother with SSL at all. How would a client algorithmically determine whether the server socket was in a secure directory? You have to configure your client to know that, but don't you need to configure your client for SSL too? Yes, but how exactly would a client know? How is a secure directory defined, in terms of C library calls, say? I assume directory permissions controlling access to the socket file would be enough. You are going to have to set up SSL certificates anyway for this so isn't that just as hard as telling the client where the socket file is located? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Bruce Momjian wrote: I thought the logical solution to this was to place the socket in a secure directory and not bother with SSL at all. How would a client algorithmically determine whether the server socket was in a secure directory? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Peter Eisentraut wrote: Bruce Momjian wrote: I thought the logical solution to this was to place the socket in a secure directory and not bother with SSL at all. How would a client algorithmically determine whether the server socket was in a secure directory? You have to configure your client to know that, but don't you need to configure your client for SSL too? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] SSL over Unix-domain sockets
I found an old patch on my disk to enable SSL over Unix-domain sockets. Remember, about a year ago it was discussed that there might also be man-in-the-middle or fake-server attacks using Unix-domain sockets, because usually anyone can start a server in /tmp. After an extensive discussion (mainly about moving the socket out of /tmp by default; please don't start that again), it was determined that using SSL server verification would be the proper solution and it fact works without problems. Except that the start-up overhead was increased significantly (because of the initial key exchange and session key setup etc.). Back then we didn't really have a good solution, but I figured since 8.4 rearranges the SSL connection parameters anyway, we could stick that in there. I imagine for example, we could invent an additional sslmode of the sort prefer-but-not-if-local-socket, which could be the default. The other question is whether sslverify=cn makes sense, but that may be up to the user to find out. Comments? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Peter Eisentraut wrote: I found an old patch on my disk to enable SSL over Unix-domain sockets. Remember, about a year ago it was discussed that there might also be man-in-the-middle or fake-server attacks using Unix-domain sockets, because usually anyone can start a server in /tmp. After an extensive discussion (mainly about moving the socket out of /tmp by default; please don't start that again), it was determined that using SSL server verification would be the proper solution and it fact works without problems. Except that the start-up overhead was increased significantly (because of the initial key exchange and session key setup etc.). Back then we didn't really have a good solution, but I figured since 8.4 rearranges the SSL connection parameters anyway, we could stick that in there. I imagine for example, we could invent an additional sslmode of the sort prefer-but-not-if-local-socket, which could be the default. That parameter is already pretty complex, not sure it's a great idea to make it even more so :( Perhaps it's enough to add a localssl row to pg_hba.conf? The other question is whether sslverify=cn makes sense, but that may be up to the user to find out. Without finding a way to have that make sense, you don't actually fix the potential MITM problem (at least not in many common scenarios), so I think that needs to be considered before we put anything in. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Magnus Hagander wrote: I imagine for example, we could invent an additional sslmode of the sort prefer-but-not-if-local-socket, which could be the default. That parameter is already pretty complex, not sure it's a great idea to make it even more so :( I think there is a firm difference between complex and having a large number of things to choose from. By your definition, a float type would be a complex. Uh ... hahah. Perhaps it's enough to add a localssl row to pg_hba.conf? That defeats the point, I think. You don't want the server to determine whether the client should verify the server. The other question is whether sslverify=cn makes sense, but that may be up to the user to find out. Without finding a way to have that make sense, you don't actually fix the potential MITM problem (at least not in many common scenarios), so I think that needs to be considered before we put anything in. Yeah, the problem is that there is only one server certificate. Is it possible/does it make sense to add an additional cn to the certificate? Another thought I had is to somehow employ hostaddr, as in hostaddr=/tmp host=real.hostname.lan. Another^2 thought is to just examine the certificate for the local host name, which the client can find out itself. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Peter Eisentraut wrote: Magnus Hagander wrote: I imagine for example, we could invent an additional sslmode of the sort prefer-but-not-if-local-socket, which could be the default. That parameter is already pretty complex, not sure it's a great idea to make it even more so :( I think there is a firm difference between complex and having a large number of things to choose from. By your definition, a float type would be a complex. Uh ... hahah. Perhaps it's enough to add a localssl row to pg_hba.conf? That defeats the point, I think. You don't want the server to determine whether the client should verify the server. Good point. OTOH, client behavior can be controlled now fine by setting it to require or prefer - I think that's enough. However, we might want a simple ssl_local=true/false parameter on the server that turns it on/off completely. That way you can use that parameter to control the performance side of things (basically to turn off SSL on unix sockets so you don't pay the overhead) and you keep using pg_hba to control the policy (because you still need a localssl line in pg_hba.conf of course). The client gets to say i require ssl in case it cares. And this is the same client that already knows if it's connecting over tcp or unix sockets... The other question is whether sslverify=cn makes sense, but that may be up to the user to find out. Without finding a way to have that make sense, you don't actually fix the potential MITM problem (at least not in many common scenarios), so I think that needs to be considered before we put anything in. Yeah, the problem is that there is only one server certificate. Is it possible/does it make sense to add an additional cn to the certificate? Yes on both. Except the current version of libpq doesn't support this :-( I was planning to add it (and still do), but the way to do it appears to be fairly complex and completely undocumented. I did some searching to find examples of it, but never followed through. Another thought I had is to somehow employ hostaddr, as in hostaddr=/tmp host=real.hostname.lan. That seems rather abusive. Another^2 thought is to just examine the certificate for the local host name, which the client can find out itself. That could work. In which case we should probably consider doing the same thing for localhost or 127.0.0.1 connections. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Peter Eisentraut wrote: I found an old patch on my disk to enable SSL over Unix-domain sockets. Remember, about a year ago it was discussed that there might also be man-in-the-middle or fake-server attacks using Unix-domain sockets, because usually anyone can start a server in /tmp. After an extensive discussion (mainly about moving the socket out of /tmp by default; please don't start that again), it was determined that using SSL server verification would be the proper solution and it fact works without problems. Except that the start-up overhead was increased significantly (because of the initial key exchange and session key setup etc.). Back then we didn't really have a good solution, but I figured since 8.4 rearranges the SSL connection parameters anyway, we could stick that in there. I imagine for example, we could invent an additional sslmode of the sort prefer-but-not-if-local-socket, which could be the default. The other question is whether sslverify=cn makes sense, but that may be up to the user to find out. I thought the logical solution to this was to place the socket in a secure directory and not bother with SSL at all. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL over Unix-domain sockets
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] 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 Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SSL over Unix-domain sockets
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/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SSL over Unix-domain sockets
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] SSL over Unix-domain sockets
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 Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SSL over Unix-domain sockets
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 Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] SSL over Unix-domain sockets
* Alvaro Herrera [EMAIL PROTECTED] [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, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] SSL over Unix-domain sockets
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 [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
Re: [HACKERS] SSL over Unix-domain sockets
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] SSL over Unix-domain sockets
Alvaro Herrera [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SSL over Unix-domain sockets
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] 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 Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SSL over Unix-domain sockets
Alvaro Herrera [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] SSL over Unix-domain sockets
Martijn van Oosterhout [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] SSL over Unix-domain sockets
On Mon, Jan 14, 2008 at 9:33 PM, in message [EMAIL PROTECTED], Tom Lane [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] SSL over Unix-domain sockets
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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] SSL over Unix-domain sockets
Peter Eisentraut [EMAIL PROTECTED] 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): [EMAIL PROTECTED] ~]$ 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 [EMAIL PROTECTED] ~]$ 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 [EMAIL PROTECTED] ~]$ 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 [EMAIL PROTECTED] ~]$ 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 ---(end of broadcast)--- TIP 2: Don't 'kill
Re: [HACKERS] SSL over Unix-domain sockets
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 [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] SSL over Unix-domain sockets
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SSL over Unix-domain sockets
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SSL over Unix-domain sockets
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SSL over Unix-domain sockets
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]
# hostsslDATABASE 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/
diff -ur ../cvs-pgsql/doc/src/sgml/client-auth.sgml ./doc/src/sgml/client-auth.sgml
--- ../cvs-pgsql/doc/src/sgml/client-auth.sgml 2008-01-05 11:58:42.0 +0100
+++ ./doc/src/sgml/client-auth.sgml 2008-01-05 13:55:28.0 +0100
@@ -97,6 +97,8 @@
A record can have one of the seven formats
synopsis
local replaceabledatabase/replaceable replaceableuser/replaceable replaceableauth-method/replaceable optionalreplaceableauth-option/replaceable/optional
+localssl replaceabledatabase/replaceable replaceableuser/replaceable replaceableauth-method/replaceable optionalreplaceableauth-option/replaceable/optional
+localnossl replaceabledatabase/replaceable replaceableuser/replaceable replaceableauth-method/replaceable optionalreplaceableauth-option/replaceable/optional
host replaceabledatabase/replaceable replaceableuser/replaceable replaceableCIDR-address/replaceable replaceableauth-method/replaceable optionalreplaceableauth-option/replaceable/optional
hostsslreplaceabledatabase/replaceable replaceableuser/replaceable replaceableCIDR-address/replaceable replaceableauth-method/replaceable optionalreplaceableauth-option/replaceable/optional
hostnossl replaceabledatabase/replaceable replaceableuser/replaceable replaceableCIDR-address/replaceable replaceableauth-method/replaceable optionalreplaceableauth-option/replaceable/optional
@@ -112,8 +114,36 @@
listitem
para
This record matches connection attempts using Unix-domain
- sockets. Without a record of this type, Unix-domain socket
- connections are disallowed.
+ sockets.
+ /para
+ /listitem
+/varlistentry
+
+varlistentry
+ termliterallocalssl/literal/term
+ listitem
+ para
+ This record matches connection attempts using Unix-domain
+ sockets, but only when the connection is made with acronymSSL/acronym.
+ /para
+
+ para
+ To make use of this option the server must be built with
+ acronymSSL/acronym support. Furthermore,
+ acronymSSL/acronym must be enabled at server start time
+ by setting the xref linkend=guc-ssl configuration parameter (see
+ xref linkend=ssl-tcp for more information).
+ /para
+ /listitem
+/varlistentry
+
+varlistentry
+ termliterallocalnossl/literal/term
+ listitem
+ para
+ This record type has the opposite logic to literallocalssl/:
+ it only matches connection attempts made over Unix-domain sockets
+ that do not use acronymSSL/acronym.
/para
/listitem
/varlistentry
@@ -144,8 +174,7 @@
listitem
para
This record matches connection attempts made using TCP/IP,
- but only when the connection is made with acronymSSL/acronym
- encryption.
+ but only when the connection is made with acronymSSL/acronym.
/para
para
diff -ur ../cvs-pgsql/src/backend/libpq/hba.c ./src/backend/libpq/hba.c
--- ../cvs-pgsql/src/backend/libpq/hba.c 2008-01-05 11:58:45.0 +0100
+++ ./src/backend/libpq/hba.c 2008-01-05 12:12:54.0 +0100
@@ -668,8 +668,36 @@
line_item = list_head(line);
/* Check the record type. */
token = lfirst(line_item);
- if (strcmp(token, local) == 0)
+ if (strcmp(token, local) == 0
+ || strcmp(token, localssl) == 0
+ || strcmp(token, localnossl) == 0)
{
+
+ if (token[5] == 's') /* localssl */
+ {
+#ifdef USE_SSL
+ /* Record does not match if we are not on an SSL connection */
+ if (!port-ssl)
+return;
+
+ /* Placeholder to require specific SSL level, perhaps? */
+ /* Or a client certificate */
+
+ /* Since we were on SSL, proceed as with normal 'local' mode */
+#else
+ /* We don't accept this keyword at all if no SSL support */
+ goto hba_syntax;
+#endif
+ }
+#ifdef USE_SSL
+ else if (token[5] == 'n') /* localnossl */
+ {
+ /* Record does not match if we are on an SSL connection */
+ if (port-ssl)
+return;
+ }
+#endif
+
/* Get the database. */
line_item = lnext(line_item);
if (!line_item)
diff -ur
Re: [HACKERS] SSL over Unix-domain sockets
Peter Eisentraut [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] SSL over Unix-domain sockets
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: [HACKERS] SSL over Unix-domain sockets
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: real0m12.909s user0m3.712s sys 0m3.056s With ssl=on it looks about like this: real1m4.741s user0m26.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/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] SSL over Unix-domain sockets
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 [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
[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/
diff -ur ../cvs-pgsql/src/backend/postmaster/postmaster.c ./src/backend/postmaster/postmaster.c
--- ../cvs-pgsql/src/backend/postmaster/postmaster.c 2008-01-04 15:55:25.0 +0100
+++ ./src/backend/postmaster/postmaster.c 2008-01-04 16:44:35.0 +0100
@@ -1448,8 +1448,8 @@
char SSLok;
#ifdef USE_SSL
- /* No SSL when disabled or on Unix sockets */
- if (!EnableSSL || IS_AF_UNIX(port-laddr.addr.ss_family))
+ /* No SSL when disabled */
+ if (!EnableSSL)
SSLok = 'N';
else
SSLok = 'S'; /* Support for SSL */
diff -ur ../cvs-pgsql/src/interfaces/libpq/fe-connect.c ./src/interfaces/libpq/fe-connect.c
--- ../cvs-pgsql/src/interfaces/libpq/fe-connect.c 2008-01-04 15:55:31.0 +0100
+++ ./src/interfaces/libpq/fe-connect.c 2008-01-04 16:51:09.0 +0100
@@ -1261,11 +1261,6 @@
* If SSL is enabled and we haven't already got it running,
* request it instead of sending the startup message.
*/
-if (IS_AF_UNIX(conn-raddr.addr.ss_family))
-{
- /* Don't bother requesting SSL over a Unix socket */
- conn-allow_ssl_try = false;
-}
if (conn-allow_ssl_try !conn-wait_ssl_try
conn-ssl == NULL)
{
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] SSL over Unix-domain sockets
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] # hostsslDATABASE 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 [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] SSL over Unix-domain sockets
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] # hostsslDATABASE 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] SSL over Unix-domain sockets
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] # hostsslDATABASE 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 [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] SSL over Unix-domain sockets
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] # hostsslDATABASE 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/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] SSL over Unix-domain sockets
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] # hostsslDATABASE 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 [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SSL over Unix-domain sockets
* Bruce Momjian [EMAIL PROTECTED] [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. 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, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] SSL over Unix-domain sockets
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] SSL over Unix-domain sockets
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
