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
