Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

Поиск
Список
Период
Сортировка
От Ashutosh Sharma
Тема Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Дата
Msg-id CAE9k0PnC9vZ2eCbW_OqmsDDXQaezGWH7iLQB_87qF0g6iZjt4w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions  (John H <johnhyvr@gmail.com>)
Ответы Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Список pgsql-hackers
Hi,

On Wed, Jun 19, 2024 at 6:06 AM John H <johnhyvr@gmail.com> wrote:
>
> Hi Ashutosh,
>
> Thanks for clarifying.
>
> > not standalone functions created independently
>
> I'm wondering why we wouldn't want to extend that functionality so
> that if users (including superusers) do want to automatically
> configure search_path
> when they're creating functions it's available.
>
> >  The difference is that installing extensions typically requires superuser privileges,
> > which is not the case with standalone functions.
>
> Yes, but inadvertent access to different roles can still occur even if
> it's not a superuser.
>
> It's not clear to me who the audience of this commit is aimed at,
> cause I see two sort of
> different use cases?
>
> 1. Make it easier for extension authors to configure search_path when
> creating functions
>
> The proposed mechanism via control file makes sense, although I would
> like to understand
> why specifying it today in CREATE FUNCTION doesn't work. Is it an
> awareness issue?
> I suppose it's easier if you only need to set it once in the control file?
> Is that ease-of-use what we want to solve?
>
> 2. Make it easier to avoid inadvertent escalations when functions are created
> (e.g CREATE EXTENSION/CREATE FUNCTION)
>
> Then I think it's better to provide users a way to force the
> search_path on functions when
> extensions are created so superusers aren't reliant on extension authors.
>

For standalone functions, users can easily adjust the search_path
settings as needed. However, managing this becomes challenging for
functions created via extensions. Extensions are relocatable, making
it difficult to determine and apply search_path settings in advance
within the extension_name--*.sql file when defining functions or
procedures. Introducing a new control flag option allows users to set
implicit search_path settings for functions created by the extension,
if needed. The main aim here is to enhance security for functions
created by extensions by setting search_path at the function level.
This ensures precise control over how objects are accessed within each
function, making behavior more predictable and minimizing security
risks, especially for SECURITY DEFINER functions associated with
extensions created by superusers.

--
With Regards,
Ashutosh Sharma.



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: IPC::Run accepts bug reports
Следующее
От: Yugo NAGATA
Дата:
Сообщение: Re: Document NULL