"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> As for inside connections, "secure" is still largely dependent on what your
> threat model is.
Indeed I think closing Postgres to access based on the unix userid of the
connecting user is the wrong threat model. That's basically saying you don't
trust the unix userid of the system in which case you're really up a creek.
On the other hand dblink allows something that most sysadmins would consider
outside the normal bounds and of concern in their threat model. It allows a
privilege escalation since it allows any user to make an arbitrary TCP unix
connection as another user. I think that's the angle this should be closed
from.
Put another way there is a fundamental incompatibility between the default
settings for Postgres and the default settings for dblink though. If you
install both and accept the default configuration for both then one subverts
the security of the other. The side that's outside the norm here is dblink,
and in fact it not only subverts Postgres but could allow an attacker to
subvert other systems' security too.
All that really has to happen is that dblink should by default not be callable
by any user other than Postgres. DBAs should be required to manually run
"GRANT EXECUTE ON dblink_connect(text) TO public;" if that's what he wants.
It would be more obvious running that command that you're allowing any user to
make connections as Postgres, and at least whatever piece of documentation
contains that instruction would be a convenient place to put a warning about
it.
The only problem with this is that dblink provides 36 different functions (why
so many?!) My first thought is it could provide a pair of plpgsql functions to
grant or revoke access to all its functions to a specified role. But perhaps
someone else has a cleverer idea.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com