Re: Hardening PostgreSQL via (optional) ban on local file system access - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Hardening PostgreSQL via (optional) ban on local file system access
Date
Msg-id CAMT0RQQmTWyem4zCwu5awgiZi6Q2no0wCBJ3EGjC-0jRYK4cLQ@mail.gmail.com
Whole thread Raw
In response to Re: Hardening PostgreSQL via (optional) ban on local file system access  (Hannu Krosing <hannuk@google.com>)
List pgsql-hackers
Having a superuser.conf file could also be used to solve another issue
- currently, if you remove the SUPERUSER attribute from all users your
only option to get it back would be to run in single-user mode. With
conf file one could add an "always" option there which makes any
matching user superuser to fix whatever needs fixing as superuser.

Cheers
Hannu

On Sat, Jun 25, 2022 at 10:54 PM Hannu Krosing <hannuk@google.com> wrote:
>
> What are your ideas of applying a change similar to above to actually
> being a superuser ?
>
> That is adding a check for "superuser being currently available" to
> function superuser() in
> ./src/backend/utils/misc/superuser.c ?
>
> It could be as simple as a flag that can be set only at startup for
> maximum speed - though the places needing superuser check are never in
> speed-critical path as far as I have seen.
>
> Or it could be more complex and dynamix, like having a file similar to
> pg_hba.conf that defines the ability to run code as superuser based on
> a set of attributes each of which could be * meaning "any"
>
> These could be
>   * database (to limit superuser to only certain databases)
>   * session user (to allow only some users to become superuser,
> including via SECURITY DEFINER functions)
>   * backend pid (this would allow kind of 2-factor authentication -
> connect, then use that session's pid to add a row to
> pg_ok_to_be_sup.conf file, then continue with your superuser-y stuff)
>   * valid-until - this lets one allow superuser for a limited period
> without fear of forgetting top disable it
>
> This approach would have the the benefit of being very low-code while
> delivering the extra protection of needing pre-existing access to
> filesystem to enable/disable .
>
> For easiest usability the pg_ok_to_be_sup.conf file should be outside
> pg_reload_conf() - either just read each time the superuser() check is
> run, or watched via inotify and reloaded each time it changes.
>
> Cheers,
> Hannu
>
> P.S: - thanks Magnus for the "please don't top-post" notice - I also
> need to remember to check if all the quoted mail history is left in
> when I just write a replay without touching any of it. I hope it does
> the right thing and leaves it out, but it just might unders some
> conditions bluntly append it anyway just in case :)



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Hardening PostgreSQL via (optional) ban on local file system access
Next
From: Thomas Munro
Date:
Subject: Re: Backends stunk in wait event IPC/MessageQueueInternal