Re: [HACKERS] SSL over Unix-domain sockets - Mailing list pgsql-patches

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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.402
diff -c -c -r1.402 runtime.sgml
*** doc/src/sgml/runtime.sgml    8 Jan 2008 18:07:38 -0000    1.402
--- doc/src/sgml/runtime.sgml    17 Jan 2008 00:20:36 -0000
***************
*** 1397,1405 ****
     connections is to use a Unix domain socket directory (<xref
     linkend="guc-unix-socket-directory">) that has write permission only
     for a trusted local user.  This prevents a malicious user from creating
!    their own socket file in that directory.  For TCP connections the server
!    must accept only <literal>hostssl</> connections (<xref
!    linkend="auth-pg-hba-conf">) and have SSL
     <filename>server.key</filename> (key) and
     <filename>server.crt</filename> (certificate) files (<xref
     linkend="ssl-tcp">). The TCP client must connect using
--- 1397,1413 ----
     connections is to use a Unix domain socket directory (<xref
     linkend="guc-unix-socket-directory">) that has write permission only
     for a trusted local user.  This prevents a malicious user from creating
!    their own socket file in that directory.
!    Additionally, you might want to set <xref
!    linkend="guc-external-pid-file"> to <literal>/tmp/.s.PGSQL.5432</> to
!    prevent spoofing for clients looking for the socket in its default
!    location.  This protection is only effective while the server is
!    running.
!   </para>
!
!   <para>
!    For TCP connections the server must accept only <literal>hostssl</>
!    connections (<xref linkend="auth-pg-hba-conf">) and have SSL
     <filename>server.key</filename> (key) and
     <filename>server.crt</filename> (certificate) files (<xref
     linkend="ssl-tcp">). The TCP client must connect using