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

From: Hannu Krosing <hannuk(at)google(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Robert Pang <robertpang(at)google(dot)com>
Subject: Hardening PostgreSQL via (optional) ban on local file system access
Date: 2022-06-24 22:08:13
Message-ID: CAMT0RQRX9j69GnrjJ2tkdy7zN_yofXUvU7iCOGdZE=jYiqX3wg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Pgsql-Hackers

As part of ongoing work on PostgreSQL security hardening we have
added a capability to disable all file system access (COPY TO/FROM
[PROGRAM] <filename>, pg_*file*() functions, lo_*() functions
accessing files, etc) in a way that can not be re-enabled without
already having access to the file system. That is via a flag which can
be set only in postgresql.conf or on the command line.

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 we had had this then for example the infamous 2020 PgCrypto worm
[1] would have been much less likely to succeed.

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)
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.

Best Regards
Hannu

-----
[1] https://www.securityweek.com/pgminer-crypto-mining-botnet-abuses-postgresql-distribution

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shawn Debnath 2022-06-24 22:19:33 Re: SLRUs in the main buffer pool - Page Header definitions
Previous Message Jelte Fennema 2022-06-24 21:48:15 Re: [PATCH] Optimize json_lex_string by batching character copying