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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Hannu Krosing <hannuk(at)google(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Pang <robertpang(at)google(dot)com>
Subject: Re: Hardening PostgreSQL via (optional) ban on local file system access
Date: 2022-06-24 23:13:23
Message-ID: 20220624231323.ef6s4ltbxsjlukcg@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

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.

> If we had had this then for example the infamous 2020 PgCrypto worm
> [1] would have been much less likely to succeed.

Meh.

> So here are a few questions to get discussion started.
>
> 1) would it be enough to just disable WRITING to the filesystem (COPY
> ... TO ..., COPY TO ... PROGRAM ...) or are some reading functions
> also potentially exploitable or at least making attackers life easier
> ?
> 2) should configuration be all-or-nothing or more fine-tunable (maybe
> a comma-separated list of allowed features) ?
> 3) should this be back-patched (we can provide batches for all
> supported PgSQL versions)

Err, what?

> 4) We should likely start with this flag off, but any paranoid (read -
> good and security conscious) DBA can turn it on.
> 5) Which file access functions should be in the unsafe list -
> pg_current_logfile is likely safe as is pg_relation_filenode, but
> pg_ls_dir likely is not. some subversions might be ok again, like
> pg_ls_waldir ?
> 6) or should we control it via disabling the pg_*_server_* roles for
> different take of configuration from 5) ?
>
> As I said, we are happy to provide patches (and docs, etc) for all the
> PostgreSQL versions we decide to support here.

I don't see anything here that provides a meaningful increase in security.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2022-06-24 23:23:36 Re: Hardening PostgreSQL via (optional) ban on local file system access
Previous Message Nathan Bossart 2022-06-24 23:06:47 Re: Hardening PostgreSQL via (optional) ban on local file system access