On Mon, Jul 09, 2007 at 06:13:54PM +0100, Gregory Stark wrote:
> I'm not suggesting making dblink super-user only. Only revoking public execute
> bits in the default install script. That doesn't affect users upgrading so I
> don't see a backwards-compatibility issue.
>
> The doc changes are going
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Joe Conway <[EMAIL PROTECTED]> 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-reque
"Tom Lane" <[EMAIL PROTECTED]> writes:
> 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.
Well typically the database is behind the firewall but an application is
outside th
Joe Conway <[EMAIL PROTECTED]> 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
Gregory Stark wrote:
"Joe Conway" <[EMAIL PROTECTED]> writes:
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
There are none installed by default -- that's the point.
Uhh... None what? Functions in untrusted languages? That's certainly
not the case, there's a whole slew of th
Stephen Frost wrote:
It's about as good as saying "Well, an admin had to install PostgreSQL
on the system, by choice, and therefore we don't need to worry about PG
allowing someone remote shell access to the system".
That's a ridiculous assertion -- I said nothing of the sort.
Joe
---
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Get serious. Internal functions are specifically designed and maintained to
> be safe within the confines of the database security model. We are
> discussing extensions to the core, all of which must be installed by
> choice, by a superuser.
Extensions
"Joe Conway" <[EMAIL PROTECTED]> writes:
> Stephen Frost wrote:
>> * Joe Conway ([EMAIL PROTECTED]) wrote:
>>> There are none installed by default -- that's the point.
>>
>> Uhh... None what? Functions in untrusted languages? That's certainly
>> not the case, there's a whole slew of them, from
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
There are none installed by default -- that's the point.
Uhh... None what? Functions in untrusted languages? That's certainly
not the case, there's a whole slew of them, from boolin to
generate_series and beyond. They're availabl
"Joe Conway" <[EMAIL PROTECTED]> writes:
> Stephen Frost wrote:
>
>> I see.. So all the functions in untrusted languages that come with PG
>> initially should be checked over by every sysadmin when installing PG
>> every time... And the same for PostGIS, and all of the PL's that use
>> untrusted
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
>> I see.. So all the functions in untrusted languages that come with PG
>> initially should be checked over by every sysadmin when installing PG
>> every time... And the same for PostGIS, and all of the PL's that use
>> untrusted lan
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
Sure it matters. A function written in a trusted language is known to be
safe, a priori. A function written in an untrusted language has no such
guarantees, and therefore has to be assumed unsafe unless carefully proved
otherwise.
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> "Joe Conway" <[EMAIL PROTECTED]> writes:
> > Consider a scenario like "package uses > untrusted language z>". Exact same concerns arise.
>
> Well arbitrary function may or may not actually do anything that needs to be
> restricted.
>
> If it does the
"Joe Conway" <[EMAIL PROTECTED]> writes:
> See my last email...
>
> Consider a scenario like "package uses untrusted language z>". Exact same concerns arise.
Well arbitrary function may or may not actually do anything that needs to be
restricted.
If it does then yes the same concerns arise an
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
>> No, it doesn't... Said arbitrary function in y, in untrusted language
>> z, could be perfectly safe for users to call.
> ^
> *Could* be. But we just said that the admin was not interested in reading
> the documentation, an
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
Consider a scenario like "package uses untrusted language z>". Exact same concerns arise.
No, it doesn't... Said arbitrary function in y, in untrusted language
z, could be perfectly safe for users to call.
^
*Could* be. Bu
"Joe Conway" <[EMAIL PROTECTED]> writes:
> Agreed.
>
> If you are going to argue that we should revoke access for non-superusers by
> default for dblink, then you are also arguing that we should do the same for
> every function created with any untrusted language.
Only if the function created use
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Consider a scenario like "package uses untrusted language z>". Exact same concerns arise.
No, it doesn't... Said arbitrary function in y, in untrusted language
z, could be perfectly safe for users to call. Being written in an
untrusted language has got
* Joe Conway ([EMAIL PROTECTED]) wrote:
> If you are going to argue that we should revoke access for non-superusers
> by default for dblink, then you are also arguing that we should do the same
> for every function created with any untrusted language.
Uh, no, one doesn't imply the other. It doe
Gregory Stark wrote:
Consider a scenario like "package uses dblink". Sysadmin follows
instructions for package and installs dblink. Now package 's
documentation isn't going to explain the second-order effects and discuss
restricting who has access to dblink. The sysadmin has no particular inter
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> My objection is that I think we should still revoke access for non-superuser
>> by default. The patch makes granting execute reasonable for most users but
>> nonetheless it shouldn't be the default.
>
>> Being ab
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
My objection is that I think we should still revoke access for non-superuser
by default. The patch makes granting execute reasonable for most users but
nonetheless it shouldn't be the default.
Being able to connect to a postgres server
Gregory Stark <[EMAIL PROTECTED]> writes:
> My objection is that I think we should still revoke access for non-superuser
> by default. The patch makes granting execute reasonable for most users but
> nonetheless it shouldn't be the default.
> Being able to connect to a postgres server shouldn't me
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> Actually from a security point of view revoking public execute is pretty much
> the same as making a function super-user-only. The only difference is how much
> of a hassle it is for the super-user to grant access. Perhaps we should
> reconsider whether
"Stephen Frost" <[EMAIL PROTECTED]> writes:
>> Being able to connect to a postgres server shouldn't mean being able to open
>> tcp connections *from* that server to arbitrary other host/ports. Consider
>> for
>> example that it would allow a user to perform a port scan from inside your
>> network
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> "Joe Conway" <[EMAIL PROTECTED]> writes:
> > If there are no objections I'll commit this later today.
>
> My objection is that I think we should still revoke access for non-superuser
> by default. The patch makes granting execute reasonable for most use
"Joe Conway" <[EMAIL PROTECTED]> writes:
> If there are no objections I'll commit this later today.
My objection is that I think we should still revoke access for non-superuser
by default. The patch makes granting execute reasonable for most users but
nonetheless it shouldn't be the default.
Bei
Joe Conway wrote:
I'm working on the back branch solution now.
Attached is for back-patching. I left in the SECURITY DEFINER functions
and dblink doc changes -- even though they may not do existing
installations much good, I think there will still be enough new 8.2.x
installations for a whi
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Attached patch implements this proposal, including documentation
changes. I'll work separately on the back-branch version.
Any comments/objections?
Looks OK in a fast scan, except that you are not following the message
style guidelines
Joe Conway <[EMAIL PROTECTED]> writes:
> Attached patch implements this proposal, including documentation
> changes. I'll work separately on the back-branch version.
> Any comments/objections?
Looks OK in a fast scan, except that you are not following the message
style guidelines here:
> +
Tom Lane wrote:
Here's a straw-man proposal that we could perhaps do for 8.3:
1. Invent a libpq connection-status function
bool PQconnectionUsedPassword(const PGconn *conn);
This returns true if the server had demanded a password during the
authentication phase. Aside from solving the
Joe Conway <[EMAIL PROTECTED]> writes:
> One question: should we provide the SECURITY DEFINER functions with
> revoked privileges or just mention that in the docs? I was thinking
> something along the lines of the following even for the backpatched version:
Hmm. I guess the advantage of providi
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
What about using the attached for 8.3, as well as earlier?
It simply does not allow the local database user to become someone else
on the libpq remote connection unless they are a superuser.
This assumes that usernames on the remote sit
Joe Conway <[EMAIL PROTECTED]> writes:
> What about using the attached for 8.3, as well as earlier?
> It simply does not allow the local database user to become someone else
> on the libpq remote connection unless they are a superuser.
This assumes that usernames on the remote site are equivalen
Tom Lane wrote:
Here's a straw-man proposal that we could perhaps do for 8.3:
What about using the attached for 8.3, as well as earlier?
It simply does not allow the local database user to become someone else
on the libpq remote connection unless they are a superuser. As Tom
noted, a simple
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> 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
On Sunday 01 July 2007 17:59, Joe Conway wrote:
> Joe Conway wrote:
> > Robert Treat wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> >>>
> >>> Well certainly dbi-link has the exact same issue.
> >>
> >> dbi-link only works in plperlu, so you've already decided your superuser
> >> only.
> >
>
Gregory Stark <[EMAIL PROTECTED]> 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 o
Joe Conway wrote:
Robert Treat wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Well certainly dbi-link has the exact same issue.
dbi-link only works in plperlu, so you've already decided your superuser only.
How so -- it is fundamentally no different than dblink, which is C
language (also unt
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I like this approach better than removing public execute privileges
> on the functions, for two reasons:
>
> * A routine minor version update would install the security fix into
> existing installations, without need for any DBA intervention.
>
> * It does
Robert Treat wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Well certainly dbi-link has the exact same issue.
dbi-link only works in plperlu, so you've already decided your superuser only.
How so -- it is fundamentally no different than dblink, which is C
language (also untrusted).
I think
Robert Treat <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I like this approach better than removing public execute privileges
>> on the functions, for two reasons:
> I think this will break backwards compatability though.
Well, revoking public execute will break backwards compatibility too.
On Sunday 01 July 2007 16:03, Joe Conway wrote:
> Tom Lane wrote:
> > Joe Conway <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> >>> 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 no
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Hmm. It would be better if it never actually completed an authentication
> in the first place, but I don't see how we can do that given how the
> protocol works.
> We could add a connection string parameter that disables it, but that
> doesn't really he
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> bool PQconnectionUsedPassword(const PGconn *conn);
> Maybe PQconnectionUsedAuthToken() to mean "data supplied by the client",
> including other potential future mechanisms?
Well, that'd not solve the pre-existing problem of how to tell
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> 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;
>>> b
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
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 imple
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 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 implementat
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
* Magnus Hagander ([EMAIL PROTECTED]) 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
Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> 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
Tom Lane wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
>> * Magnus Hagander ([EMAIL PROTECTED]) 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 expo
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Magnus Hagander ([EMAIL PROTECTED]) 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
* Magnus Hagander ([EMAIL PROTECTED]) 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
"Robert Treat" <[EMAIL PROTECTED]> 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 dblin
Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> 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
> secu
Robert Treat <[EMAIL PROTECTED]> 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 no
On Sunday 01 July 2007 13:15, Gregory Stark wrote:
> "Joe Conway" <[EMAIL PROTECTED]> 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
"Joe Conway" <[EMAIL PROTECTED]> 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
> genera
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 refere
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
Index: contrib/dblink/dblink.sql.in
60 matches
Mail list logo
