Thread: 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.
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: https://www.postgresql.org/message-id/flat/1357905627.24219.6.camel%40vanquo.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: > https://www.postgresql.org/message-id/flat/1357905627.24219.6.camel%40vanquo.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. Yes, that should certainly be fixed now thanks to pg_init_privs. If it isn't, I'd like to know... Thanks, Stephen
Attachment
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
Attachment
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 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.
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.
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.
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.