Patch based on recent -hackers discussions, it removes usage from public, and
adds a note to the documentation about why this is neccessary.

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


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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 suppose this ought to be applied back through the 7.3 branch?


Joe

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

"Joe Conway" <mail@joeconway.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.

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.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Sunday 01 July 2007 13:15, Gregory Stark wrote:
> "Joe Conway" <mail@joeconway.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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Robert Treat <xzilla@users.sourceforge.net> writes:
> Did you mean s/trust/ident/g, otherwise I don't think I understand the
> above...

Both trust and ident local auth are sources of risk for this, although
ident is particularly nasty since the DBA probably thinks he's being
secure.

For that matter, I'm not sure that *any* auth method except password
offers much security against the problem; don't LDAP and Kerberos
likewise rely mostly on process-level identity? And possibly PAM
depending on which PAM plugin you're using?

I'm not sure whether this is something to back-patch, though, since
a back-patch will accomplish zero for existing installations.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
>> Did you mean s/trust/ident/g, otherwise I don't think I understand the
>> above...
>
> Both trust and ident local auth are sources of risk for this, although
> ident is particularly nasty since the DBA probably thinks he's being
> secure.
>
> For that matter, I'm not sure that *any* auth method except password
> offers much security against the problem; don't LDAP and Kerberos
> likewise rely mostly on process-level identity? And possibly PAM
> depending on which PAM plugin you're using?

LDAP is not affected - it requires the user to enter a password. Same
would be for any PAM plugins that actually require the user to enter a
password, I think.

Kerberos is not affected either, because the server does not get a copy
of the ticket. In theory it could be affected if the server requested a
delegation enabled ticket, and exported it so it could be used, but none
of these are done.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"Robert Treat" <xzilla@users.sourceforge.net> writes:

>> 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.

Er quite right. Moreover it's not even true that ``"if "ident" authentication
is disabled this is no longer an issue''. It's still possible to have other
restrictions in pg_hba which dblink would allow you to circumvent. That
sentence is too generous of a promise.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

* Magnus Hagander (magnus@hagander.net) wrote:
> LDAP is not affected - it requires the user to enter a password. Same
> would be for any PAM plugins that actually require the user to enter a
> password, I think.

Agreed.

> Kerberos is not affected either, because the server does not get a copy
> of the ticket. In theory it could be affected if the server requested a
> delegation enabled ticket, and exported it so it could be used, but none
> of these are done.

That's quite a stretch even there, imv anyway... It'd have to be put
somewhere a backend connecting would think to look for it, given that
the user can't change the environment variables and whatnot (I don't
think) of the backend process... Regardless, strong wording against
allowing users to issue arbitrary connect's from a backend process is
appropriate, regardless of what's affected exactly (as that could
possibly change over time anyway too...).

Thanks,

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGh/fPrzgMPqB3kigRAkjgAJ9S4e9lg6maPWzSRewTIQ9w9n9rAQCg gerv
tLZMJNhlZxT237z2fiLdx2E=
=5R58
-----END PGP SIGNATURE-----

Stephen Frost <sfrost@snowman.net> writes:
> * Magnus Hagander (magnus@hagander.net) wrote:
>> Kerberos is not affected either, because the server does not get a copy
>> of the ticket. In theory it could be affected if the server requested a
>> delegation enabled ticket, and exported it so it could be used, but none
>> of these are done.

> That's quite a stretch even there, imv anyway... It'd have to be put
> somewhere a backend connecting would think to look for it, given that
> the user can't change the environment variables and whatnot (I don't
> think) of the backend process...

Hmm. I think what you are both saying is that if the remote end wants
Kerberos auth then you would expect a dblink connection to always fail.
If so, then we still seem to be down to the conclusion that there
are only three kinds of dblink connection:
* those that require a password;
* those that don't work;
* those that are insecure.

Would it be sensible to change dblink so that unless invoked by a
superuser, it fails any connection attempt in which no password is
demanded? I am not sure that this is possible without changes to libpq;
but ignoring implementation difficulties, is this a sane idea from
the standpoint of security and usability?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Magnus Hagander (magnus@hagander.net) wrote:
>>> Kerberos is not affected either, because the server does not get a copy
>>> of the ticket. In theory it could be affected if the server requested a
>>> delegation enabled ticket, and exported it so it could be used, but none
>>> of these are done.
>
>> That's quite a stretch even there, imv anyway... It'd have to be put
>> somewhere a backend connecting would think to look for it, given that
>> the user can't change the environment variables and whatnot (I don't
>> think) of the backend process...
>
> Hmm. I think what you are both saying is that if the remote end wants
> Kerberos auth then you would expect a dblink connection to always fail.
> If so, then we still seem to be down to the conclusion that there
> are only three kinds of dblink connection:
> * those that require a password;
> * those that don't work;
> * those that are insecure.
>
> Would it be sensible to change dblink so that unless invoked by a
> superuser, it fails any connection attempt in which no password is
> demanded? I am not sure that this is possible without changes to libpq;
> but ignoring implementation difficulties, is this a sane idea from
> the standpoint of security and usability?

Not sure. That would break any attempts of implementing delegation in
Kerberos for dblink, but I don't know if we're interested in doing that
anyway.

BTW, what I wrote about delegation before is wrong, of course. If
delegation worked, in that pg requested a delegation enabled ticket and
exported it through the dblink connection, it would authenticate as the
user that authenticated to the original database, not as the superuser
or anything like that. So delegation would actually be perfectly secure.
If implemented properly of course.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq