Re: Allowing to create LEAKPROOF functions to non-superuser

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allowing to create LEAKPROOF functions to non-superuser
Date: 2021-04-19 20:25:13
Message-ID: CA+TgmoYgnx9vuNzPHLt6E9hHK=qb1qQQ4a+uG64=VkvkEtWQwg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 16, 2021 at 3:57 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Mon, Apr 12, 2021 at 02:35:27PM -0700, Andres Freund wrote:
> > On 2021-04-12 17:14:20 -0400, Tom Lane wrote:
> > > I doubt that falsely labeling a function LEAKPROOF can get you more
> > > than the ability to read data you're not supposed to be able to read
> > > ... but that ability is then available to all users, or at least all
> > > users who can execute the function in question. So it definitely is a
> > > fairly serious security hazard, and one that's not well modeled by
> > > role labels. If you give somebody e.g. pg_read_all_data privileges,
> > > you don't expect that that means they can give it to other users.
>
> I do expect that, essentially. Like Andres describes for BYPASSRLS, they can
> create and GRANT a SECURITY DEFINER function that performs an arbitrary query
> and returns a refcursor (or stores the data to a table of the caller's
> choosing, etc.). Unlike BYPASSRLS, they can even make pg_read_all_data own
> the function, making the situation persist after one drops the actor's role
> and that role's objects.

Yes. I think that if someone can read all the data, it's unworkable to
suppose that they can't find a way to delegate that ability to others.
If nothing else, a station wagon full of tapes has a lot of bandwidth.

> > A user with BYPASSRLS can create public security definer functions
> > returning data. If the concern is a BYPASSRLS user intentionally
> > exposing data, then there's not a meaningful increase to allow defining
> > LEAKPROOF functions.
>
> Hence, I do find it reasonable to let pg_read_all_data be sufficient for
> setting LEAKPROOF. I would not consult datdba, because datdba currently has
> no special read abilities. It feels too weird to let BYPASSRLS start
> affecting non-RLS access controls. A reasonable person may assume that
> BYPASSRLS has no consequences until someone uses CREATE POLICY. That said, I
> wouldn't be horrified if BYPASSRLS played a part. BYPASSRLS, like
> pg_read_all_data, clearly isn't something to grant lightly.

I agree that datdba doesn't seem like quite the right thing, but I'm
not sure I agree with the rest. How can we say that leakproof is a
non-RLS access control? Its only purpose is to keep RLS secure, so I
guess I'd be inclined to think that of the two, BYPASSRLS is more
closely related to the topic at hand.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-04-19 20:32:36 Re: Allowing to create LEAKPROOF functions to non-superuser
Previous Message Tom Lane 2021-04-19 20:21:17 Re: Bogus collation version recording in recordMultipleDependencies