Secure Postgres access

[Paul Rubin]

Reid Priedhorsky <reid at reidster.net> writes:
> B) Work machine. Run by others, many users. I'd like to also run my
> database client (Python) here.

Well, just how much do you distrust that machine?  If you think it's
totally pwned by attackers who will stop at nothing to subvert your
client, you shouldn't run the client there.  How do you propose to
open an SSH connection from a completely untrusted box, for example?
You can't type an SSH password into it since you have to assume that
the keystrokes are being logged.

If you only partially distrust the machine, then figure out what
operations on it you do trust, and work from there.

> What I'd like is functionality similar to what Subversion does with
> "svn+ssh://" URLs: an SSH tunnel that accepts only one connection and
> doesn't have race conditions.

That doesn't sound like the right answer.  It means you have to
carefully arrange your application to open just one db connection and
use it throughout its run.  Many applications are somewhat cavalier
about opening and closing db conns, and and it's sometimes convenient
to write in that style.  Some apps (e.g. multi-threaded ones)
inherently require multiple db conns.  And even if you have an SSH
mode that accepts just one connection, since your db app is separate
and has to connect to the forwarding port after you use a separate
program open the port, how do you stop someone else from grabbing it
first?

I think what you really want is normal, multi-connection SSH port
forwarding to the db server, but that works only for you and doesn't
work for others.  That seems to mean one of:

  1) authentication (like a db password) in the db client, maybe using
     another process that the db client gets a credential from
  2) authentication through SCM_CREDENTIALS on a PF_UNIX socket
  3) authentication via identd on the client machine (i.e. you trust
     the admins on that machine to keep malicious stuff off of the
     privileged ports)
  4) some other scheme yet to be identified

Actually, looking at the doc for ssh-agent(1), it looks like it might
do something like #2 above.  If I understand it, you would run your db
client as something like

   ssh-agent your-client &

and the ssh agent would start your client, exporting an env variable
that your client can use to start ssh without a password and connect
to the db server.  The env variable points to a PF_UNIX socket where
the doc says "the socket is made accessible only to the current user".
Although the docs aren't totally clear, this sounds sort of like what
we're discussing, so I'd say it's worth looking into.

Finally, lately for unrelated reasons I've been looking at Vtun
(vtun.sf.net), a simple VPN program that might be easier to modify
than OpenSSH.  Its security features look worse than ssh's, but maybe
they're enough for your purpose.