Re: dblink connection security - Mailing list pgsql-patches

From Stephen Frost
Subject Re: dblink connection security
Date
Msg-id 20070709183352.GY4887@tamriel.snowman.net
Whole thread Raw
In response to Re: dblink connection security  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Joe Conway <mail@joeconway.com> writes:
> > But if you know of a security risk related to using libpq
> > with a password authenticated connection, let's hear it.
>
> As near as I can tell, the argument is that dblink might be used to send
> connection-request packets to random addresses.  Now this is only a

Yes.

> security issue if the attacker could not have reached such an address
> directly; otherwise he might as well send the packet himself (and have a

No.  Being able to come from a different address is valuable even if you
can get to that address directly yourself.

> lot more control over its content).  So I guess the scenario is that
> you're running your database on your firewall machine, where it is
> accessible from outside your net but also can reach addresses inside.

It wouldn't need to be "on your firewall", just behind it, which is
extremely common.

> And you're letting untrustworthy outside people log into the database.

It's not nearly so convoluted.  SQL injections happen.

> And you put dblink on it for them to use.  And even then, the amount of
> damage they could do seems pretty limited due to lack of control over
> the packet contents.

dblink could have been installed for a variety of reasons.  Making it
openly available on install makes it much less likely any additional
restrictions were placed on it.

> To me this scenario is too far-fetched to justify sacrificing
> convenience and backwards compatibility.  It should be sufficient to add
> some paragraphs about security considerations to the dblink docs.

I feel that requiring a sysadmin to issue a 'grant' if they want
that convenience is justified and reasonable.  We could include the
statement itself in the documentation we're expecting them to read
anyway so they can just copy & paste it.  Adding paragraphs to the
documentation is good but doesn't justify a insecure-by-default
approach.

Regardless of what core ends up doing, I'm hopeful it'll be disabled by
default under Debian.  It'd certainly be easier if it was done upstream.

    Thanks,

        Stephen

Attachment

pgsql-patches by date:

Previous
From: Gregory Stark
Date:
Subject: Re: dblink connection security
Next
From: daveg
Date:
Subject: Re: dblink connection security