Re: dblink connection security

On Sunday 01 July 2007 13:15, Gregory Stark wrote:
> "Joe Conway" <mail(at)joeconway(dot)com> writes:
> > Robert Treat wrote:
> >> Patch based on recent -hackers discussions, it removes usage from
> >> public, and adds a note to the documentation about why this is
> >> neccessary.
> >
> > I agree with the fix as the simplest and most sensible approach, and in
> > general with the doc change, but I'm not inclined to reference the
> > security paper. Maybe something like:
> >
> > As a security precaution, dblink revokes access from PUBLIC role
> > usage for the dblink_connect functions. It is not safe to allow
> > remote users to execute dblink from a database in a PostgreSQL
> > installation that allows local account access using the "trust"
> > authentication method. In that case, remote users could gain
> > access to other accounts via dblink. If "trust" authentication
> > is disabled, this is no longer an issue.
>
> I think putting the emphasis on Postgresql trust authentication is missing
> the broader point. I would suggest two paragraphs such as:
>
> dblink allows any connected user to attempt to connect to TCP/IP or Unix
> sockets from the database server as the user the database system is
> running. This could allow users to circumvent access control policies based
> on the connecting user or the connecting host.
>
> In particular Postgres's "trust" authentication is one such system. It
> authenticates connecting users based on the unix userid of the process
> forming the connection. In typical configurations any user who is granted
> execute access to dblink can form connections as the "postgres" user which
> is the database super-user. If "trust" authentication is disabled this is
> no longer an issue.
>

Did you mean s/trust/ident/g, otherwise I don't think I understand the
above... granted the combination of trust for localhost does open a door
for remote users if they have access to dblink, but I don't think that's what
you were trying to say.

> Therefore dblink requires you to explicitly grant execute privileges to
> users or roles you wish to allow to form connections. It does not grant
> these privileges to the PUBLIC role by default as other packages typically
> do.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL