Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

Поиск
Список
Период
Сортировка
От Ashutosh Sharma
Тема Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Дата
Msg-id CAE9k0P=Aoo1FDGjRKPoRJiBMQq-yLRLTJSO6r5+ffoc+XqaeYA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Список pgsql-hackers
Дерево обсуждения
Hi,

On Thu, Jun 6, 2024 at 2:36 AM Jeff Davis <pgsql@j-davis.com> wrote:
On Wed, 2024-06-05 at 14:36 +0530, Ashutosh Sharma wrote:
> Thank you, Ashutosh, for the quick response. I've drafted a patch
> aimed at addressing this issue. The patch attempts to solve this
> issue by configuring the search_path for all security definer
> functions created by the extension.

I like the general direction you propose, but I think it needs more
discussion about the details.

I agree.
 

* What exactly is the right search_path for a function defined in an
extension?

Determining the precise value can be challenging. However, since it's a function installed by an extension, typically, the search_path should include the extension's search_path and the schema where the function resides. If the function relies on a schema other than the one we set in its search_path, which would usually be the one created by the extension, this approach will enforce the extension developers to set the extension's specific search_path in the create function statement, if it's not set. The primary goal here is to ensure that the security definer functions created by an extension do not refer to any untrusted schema(s).
 

* Do we need a new magic search_path value of "$extension_schema" that
resolves to the extension's schema, so that it can handle ALTER
EXTENSION ... SET SCHEMA?

Possibly yes, we can think about it, I think it would be something like the $user we have now.
 

* What do we do for functions that want the current behavior and how do
we handle migration issues?


That can be controlled via some GUC if needed, I guess.
 

* What about SECURITY INVOKER functions? Those can still be vulnerable
to manipulation by the caller by setting search_path, which can cause
an incorrect value to be returned. That can matter in some contexts
like a CHECK constraint.

I didn't get you completely here. w.r.t extensions how will this have an impact if we set the search_path for definer functions. 

--
With Regards,
Ashutosh Sharma.

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: question regarding policy for patches to out-of-support branches
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: ResourceOwner refactoring