Re: Hardening PostgreSQL via (optional) ban on local file system access

On Sat, Jun 25, 2022 at 1:13 AM Andres Freund <andres(at)anarazel(dot)de> wrote:

>
> On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
> > Currently the file system access is controlled via being a SUPREUSER
> > or having the pg_read_server_files, pg_write_server_files and
> > pg_execute_server_program roles. The problem with this approach is
> > that it will not stop an attacker who has managed to become the
> > PostgreSQL SUPERUSER from breaking out of the server to reading and
> > writing files and running programs in the surrounding container, VM or
> > OS.
>
> If a user has superuser rights, they automatically can execute arbitrary
> code. It's that simple. Removing roles isn't going to change that. Our code
> doesn't protect against C functions mismatching their SQL level
> definitions. With that you can do a lot of things.
>

Yeah, trying to close this hole is a *very* large architectural change.

I think a much better use of time is to further reduce the *need* to use
superuser to the point that the vast majority of installations can run
without having it. For example the addition of the pg_monitor role has made
a huge difference to the number of things needing superuser access. As doe
the "grantable gucs" in 15, for example. Enumerating what remaining things
can be done safely without such access and working on turning that into
grantable permissions or roles will be a much safer way to work on the
underlying problem (which definitely is a real one), and as a bonus that
gives a more granular control over things even *beyond* just the file
system access.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>