Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

From: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: John H <johnhyvr(at)gmail(dot)com>, Alexander Kukushkin <cyberdemn(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Date: 2024-06-26 05:49:12
Message-ID: CAE9k0Pmr4cOUmTQV3yv0QtHfjG8Rw93MycGpjSKfrsXFsFC71Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 25, 2024 at 12:40 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> On Wed, 2024-06-19 at 08:53 +0530, Ashutosh Sharma wrote:
> > 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.
>
> A special search_path variable "$extension_schema" would be a better
> solution to this problem. We need something like that anyway, in case
> the extension is relocated, so that we don't have to dig through the
> catalog and update all the settings.
>
> > 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,
>
> That leaves me wondering whether it's being addressed at the right
> level.
>
> For instance, did you consider just having a GUC to control the default
> search_path for a function? That may be too magical, but if so, why
> would an extension-only setting be better?
>

I haven't given any such thought, my current focus is on extensions,
specifically increasing their security with respect to superuser
elevation.

Regarding your first question which you had raised earlier : "What
exactly is the right search_path for a function defined in an
extension?"

As I understand it, we cannot precisely determine the search_path for
functions at the time of function creation in the code. The most
accurate path (or something close to it) we can identify for functions
created by extensions is the search_path set by the extension during
its creation, which is what we aim to achieve with $extension_schema.
This setting is up to the discretion of the author as to whether they
are comfortable with this implicit search_path configuration at the
function level. If not, they have the option to disable it. However,
AFAIU, in most cases, especially when the extension can be relocated,
this situation is unlikely to occur.

--
With Regards,
Ashutosh Sharma,

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2024-06-26 06:00:11 Re: Should we document how column DEFAULT expressions work?
Previous Message Michael Paquier 2024-06-26 05:39:57 Re: Fix possible overflow of pg_stat DSA's refcnt