Greetings, * Mark Dilger (mark.dil...@enterprisedb.com) wrote: > > On Jul 23, 2021, at 6:22 AM, Robert Haas <robertmh...@gmail.com> wrote: > > And I think that's a good illustration of why it's a bad idea to > > categorize things according to whether or not they have a certain > > consequence. > > Well, one very big reason for wanting to break superuser into separate roles > is to make postgres-as-a-service providers comfortable granting more > privileges to customers. If we design any privilege escalations into one of > those roles, then no sensible service provider is ever going to grant it to > anybody, which fairly much defeats the purpose of this work. The privilege > escalations we need to prevent are not just escalations to superuser, but > also escalations to other privileged roles. Contrary to this design goal, > the "pg_host_security" role is a bit of a synonym for "superuser", since > being able to write files or execute shell commands is a path to superuser, > and we can't do too much about that. "pg_database_security", > "pg_network_security", and "pg_logical_replication" are not synonyms for > "superuser". > > I like your idea of designing some extra security around event triggers to > resolve their privilege escalation problems. A GUC seems the wrong approach > to me. > > I think a superuser-only GUC to suppress firing event triggers won't quite > cut it, because the other privileged roles would still be in danger of being > trapped by a clever pg_database_security event trigger author; but extending > permissions on the GUC to include the other roles would mean that they, and > not just superuser, could evade event trigger based auditing solutions. That > is odd, because you wouldn't expect granting pg_network_security or > pg_logical_replication to have anything to do with granting privilege to > defeat audit logging.
These considerations were addressed with row_security by allowing the GUC to be set by anyone, but throwing an ERROR if RLS would have been required by the query instead of just allowing it. I don't see any obvious reason why that couldn't be the case for event triggers..? > A superuser-only GUC for this is also a bit too heavy handed. The superuser > may not want to circumvent all event triggers, just those put in place by the > pg_database_security role. If that sounds arbitrary, just consider the > postgres-as-a-service case. The superuser wants to be able to grant > pg_database_security to the customer, but doesn't want the customer to be > able to use that to trap the service provider. Having a trust system for triggers, functions, etc, where you can say whose triggers you're ok running might be interesting but it also seems like an awful lot of work and I'm not sure that it's actually really that much better than a GUC similar to row_security. > Instead of a GUC, how about checking permissions inside event triggers for > both the user firing the trigger *and* the trigger owner. That's a backward > compatibility break, but maybe not a bad one, since until now only superusers > have been allowed to create event triggers. Systems which create an event > trigger using a role that later has superuser revoked, or which change > ownership to a non-superuser, will see a behavior change. I'm not super > happy with that, but I think it is better than the GUC based solution. Event > triggers owned by a superuser continue to work as they do now. Event > triggers owned by a non-superuser cannot be used to force a privileged user > to run a command that the event trigger owner could not have run for themself. I'm not following what this suggestion is, exactly. What permissions are being checked inside the event trigger being run, exactly..? Who would get to set those permissions? Any object owner, today, can GRANT access to any other user in the system, we don't prevent that. Thanks, Stephen
signature.asc
Description: PGP signature
