Re: pgsql: Fix search_path to a safe value during maintenance operations.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2023-06-29T15:19:38Z
Lists: pgsql-hackers
[ emerges from hibernation ] On Mon, Jun 19, 2023 at 6:58 PM Jeff Davis <pgsql@j-davis.com> wrote: > On Mon, 2023-06-19 at 16:03 -0400, Robert Haas wrote: > > I'm inclined to think that this is a real security issue and am not > > Can you expand on that a bit? You mean a practical security issue for > the intended use cases? Yeah. I mean, as things stand, it seems like giving someone the MAINTAIN privilege will be sufficient to allow them to escalate to the table owner if there are any expression indexes involved. That seems like a real problem. We shouldn't ship a new feature with a built-in security hole like that. I was pretty outraged when I realized that we'd been shipping releases for years where CREATEROLE let you grab superuser because you could just grant yourself pg_execute_server_program and then go to town. Ideally, that hazard should have been identified and fixed in some way before introducing pg_execute_server_program. I don't know whether the hazard wasn't realized at the time or whether somebody somehow convinced themselves that that was OK, but it clearly isn't. Now we're proposing to ship a brand-new feature with a hole that we definitely already know exists. I can't understand that at all. Should we just go file the CVE against ourselves right now, then? Seriously, what are we doing? If we're not going to fix the feature so that it doesn't break the security model, we should probably just revert it. I don't understand at all the idea of shipping something that we 100% know is broken. > > very sanguine about waiting another year to fix it, but at the same > > time, I'm somewhat worried that the proposed fix might be too narrow > > or wrongly-shaped. I'm not too convinced that we've properly > > understood what all of the problems in this area are. :-( > > Would it be acceptable to document that the MAINTAIN privilege (along > with TRIGGER and, if I understand correctly, REFERENCES) carries > privilege escalation risk for the grantor? That's clearly better than nothing, but also seems like it's pretty clearly the wrong approach. If somebody electrocutes themselves on the toaster in the break room, you don't stick a sign on the side of it that says "this toaster will electrocute you if you try to use it" and then call it good. You either fix or replace the toaster, or at the very least throw it out, or at the VERY least unplug it. I am failing to understand how this situation is any different. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Fix search_path to a safe value during maintenance operations.
- 2af07e2f749a 17.0 landed
- 05e173735171 16.0 cited
-
Revert MAINTAIN privilege and pg_maintain predefined role.
- 957445996fda 16.0 landed
- 151c22deee66 17.0 landed
-
Add grantable MAINTAIN privilege and pg_maintain role.
- 60684dd834a2 16.0 cited
-
Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner.
- b073c3ccd06e 15.0 cited