"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Gregory Stark <stark@enterprisedb.com> writes:
>> I think there are two problems with this:
>
>> a) dblink still shouldn't allow arbitrary users to open arbitrary tcp/ip
>> sockets or unix sockets from the server. That's still a security threat
>> even if we close Postgres's vulnerability to it.
>
> The only way we could enforce that would be to completely disallow
> non-superuser use of dblink; ie, "if (!superuser()) elog(ERROR)",
> nothing so weak as revoking public execute access. That's a good deal
> further than I'm prepared to go, as it really does take away
> functionality. And it does it in order to close someone else's security
> problem, so I think it's a pretty bad tradeoff.
Well first of all this isn't someone else's security problem. dblink is the
one allowing the privilege escalation: it allows user stark on box A to create
sockets on box B as user postgres. The other services are not at fault for
trusting that a connection from box B as user postgres was made by someone
with the privilege to do so.
While restricting dblink_connect() to superuser would guarantee nobody ever
have a problem merely removing the privilege from non-superusers would at
least require the sysadmin to consider which users should have the privilege
of creating connections as the postgres user and grant only those users the
ability. As long as it's the sysadmin doing the granting and not the install
script that's fine.
Fwiw I don't see much distinction between restricting a function to superuser
only and only granting initial privileges to superuser. In either case a
sysadmin can grant access to non-superusers, it's just more convenient in the
latter case as the former case requires security definer functions.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
