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