Re: pgsql: Fix search_path to a safe value during maintenance operations.

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pgsql: Fix search_path to a safe value during maintenance operations.
Дата
Msg-id CA+TgmoZVCHERUkXhAMT2Er-sKBc5C6_iX+TpxxivBevDHzq2TQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: pgsql: Fix search_path to a safe value during maintenance operations.  (Andrew Dunstan <andrew@dunslane.net>)
Re: pgsql: Fix search_path to a safe value during maintenance operations.  (Nathan Bossart <nathandbossart@gmail.com>)
Re: pgsql: Fix search_path to a safe value during maintenance operations.  (Jeff Davis <pgsql@j-davis.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alena Rybakina
Дата:
Сообщение: Re: POC, WIP: OR-clause support for indexes
Следующее
От: Andres Freund
Дата:
Сообщение: Re: ReadRecentBuffer() doesn't scale well