dblink security - Mailing list pgsql-hackers

In the PL/Proxy thread it was pointed out that plproxy + dblink
combination can create security hole if .pgpass is used for
storing the passwords for connections.  Although plproxy allows
keeping passwords in several places - function body, data,
even reading from text file - keeping them in .pgpass (or pg_service)
is preferred as it's both easy and secure.  Also giving
simple filter which users are allowed to use plproxy.

Use of .pgpass is good for other usual reasons - making psql
use easy, passwords for scripts - as keeping them in .ini files
is not good as they may be backed up to CVS or simply pasted around.

And all the regular usage situations stay secure if PL/Proxy is added
to the mix.  In fact no other libpq-in-db solution (dbi-link,
hand-coded plperl/plpython functions) do not break .pgpass
security.  Because they do not let normal users to specify
libpq connect string (unless explicitly coded).

But all the regular usage situations break if dblink is added
to the mix.

So now I am on opinion that it's a plain old security hole
in dblink: it exposes the passwords specified in postgres users
pgpass/pg_service/PGPASSWORD to the world.

There are some hacks added to libpq/dblink to avoid this, but they are
pointless, as they are applied _after_ the connection is established.
User just needs to direct the connection to his laptop first
to fetch the password.

In addition there are some less severe problems:

- dblink can be used to bruteforce passwords
- dblink can be used to open any amount of connections, thus can be used to DoS random servers.
- As the connection can be directed to machine under control of user, it opens a possibility to exploit dblink/libpq
bugswhich otherwise would not be security-critical.
 
- Possibility of data leak - user can send data out from database.

IOW - anything that lets regular database user to create libpq
connection to freely specified connection string creates security hole.

Possible solutions:

* Remove dblink
* Replace it with dbi-link / plproxy / something else
* Let it stay as-is, declare .pgpass should not be used.
* Lessen the impact by: - hack libpq to disallow to overwrite params from pg_service in connstr - hack libpq to not
read.pgpass/pg_service/env at all,   or just skip passwords from there. - pointing to dbi-link and pl/proxy as secure
alternatives.- tagging is as 'security hole'
 
* Fix dblink: - Make functions that take connect strings runnable only by superuser - Add a way for superuser to
specifyname -> connect-string pairs,   so that regular users can only specify connections by name.   And only one
connectonper name.  Btw that would be the path   to get rid of manual connection management in dblink. - Add plproxy
logicof adding user= if missing, thus avoiding   implicit user=postgres connections.
 

Feel free to pick any combination.

-- 
marko