untrusted PLs should be GRANTable
Hi all
A user has raised the point that our refusal to GRANT rights to untrusted
PLs is counterproductive and inconsistent with how we behave elsewhere.
Yes, untrusted PLs can be escaped to gain superuser rights, often trivially.
But we allow this:
CREATE ROLE superme SUPERUSER NOINHERIT;
GRANT superme TO me;
.... and really, GRANTing an untrusted PL is similar.
Forcing users to create their PLs as a superuser increases the routine use
of superuser accounts. Most users' DDL deploy scripts will get be run as a
superuser if they have to use a superuser for PL changes; they're not going
to SET ROLE and RESET ROLE around the function changes.
It also encourages users to make their untrusted functions SECURITY DEFINER
when still owned by a superuser, which we really don't want them doing
unnecessarily.
In the name of making things more secure, we've made them less secure.
Untrusted PLs should be GRANTable with a NOTICE or WARNING telling the
admin that GRANTing an untrusted PL effectively gives the user the ability
to escape to superuser.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 17.07.18 07:20, Craig Ringer wrote:
A user has raised the point that our refusal to GRANT rights to
untrusted PLs is counterproductive and inconsistent with how we behave
elsewhere.
Previous discussion:
/messages/by-id/1357905627.24219.6.camel@vanquo.pezone.net
What caused that to die was "What might actually be a problem in this
area is that, AFAICT, pg_dump does not save privileges granted to
objects in extensions." But I think that is fixed/fixable now with
pg_init_privs.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Jul 17, 2018 at 1:20 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
Forcing users to create their PLs as a superuser increases the routine use
of superuser accounts. Most users' DDL deploy scripts will get be run as a
superuser if they have to use a superuser for PL changes; they're not going
to SET ROLE and RESET ROLE around the function changes.It also encourages users to make their untrusted functions SECURITY DEFINER
when still owned by a superuser, which we really don't want them doing
unnecessarily.In the name of making things more secure, we've made them less secure.
Untrusted PLs should be GRANTable with a NOTICE or WARNING telling the admin
that GRANTing an untrusted PL effectively gives the user the ability to
escape to superuser.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Greetings,
* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
On 17.07.18 07:20, Craig Ringer wrote:
A user has raised the point that our refusal to GRANT rights to
untrusted PLs is counterproductive and inconsistent with how we behave
elsewhere.Previous discussion:
/messages/by-id/1357905627.24219.6.camel@vanquo.pezone.netWhat caused that to die was "What might actually be a problem in this
area is that, AFAICT, pg_dump does not save privileges granted to
objects in extensions." But I think that is fixed/fixable now with
pg_init_privs.
Yes, that should certainly be fixed now thanks to pg_init_privs. If it
isn't, I'd like to know...
Thanks,
Stephen
Greetings,
* Craig Ringer (craig@2ndquadrant.com) wrote:
Untrusted PLs should be GRANTable with a NOTICE or WARNING telling the
admin that GRANTing an untrusted PL effectively gives the user the ability
to escape to superuser.
I don't know that we really want to get into the business of issuing a
NOTICE or WARNING in such cases. We don't do that in a lot of other
cases where non-superusers can be GRANT'd access which would allow them
to become a superuser and if we start doing it now then we're going to
need to go back and change the existing places to have such NOTICE or
WARNING, or we'll be inconsistent about it, which would be worse. I
also worry that we'd start wanting to have NOTICEs for when we are
allowing users to GRANT roles (like pg_monitor) that might get access to
data that isn't obvious, even if they aren't able to become a superuser
and it just gets ugly.
Thanks!
Stephen
On 19 July 2018 at 08:23, Stephen Frost <sfrost@snowman.net> wrote:
Greetings,
* Craig Ringer (craig@2ndquadrant.com) wrote:
Untrusted PLs should be GRANTable with a NOTICE or WARNING telling the
admin that GRANTing an untrusted PL effectively gives the user theability
to escape to superuser.
I don't know that we really want to get into the business of issuing a
NOTICE or WARNING in such cases. We don't do that in a lot of other
cases where non-superusers can be GRANT'd access which would allow them
to become a superuser and if we start doing it now then we're going to
need to go back and change the existing places to have such NOTICE or
WARNING, or we'll be inconsistent about it, which would be worse. I
also worry that we'd start wanting to have NOTICEs for when we are
allowing users to GRANT roles (like pg_monitor) that might get access to
data that isn't obvious, even if they aren't able to become a superuser
and it just gets ugly.
Good point.
I was mostly trying to anticipate concerns about people unwittingly
granting access to untrusted languages.
But hey, if you're using GRANT you should know what it means.
Alternately,
GRANT USAGE ON [UNTRUSTED] LANGUAGE plpythonu;
and if you don't write UNTRUSTED we emit the existing error?
It at least means people have to think about it and recognise the
difference.
Not really convinced it's worth the hassle, but the "u" suffix isn't what
you'd call clearly a self-documenting warning of superuser-equivalent
rights either.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services