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

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Hardening PostgreSQL via (optional) ban on local file system access
Дата
Msg-id CAMT0RQRX9j69GnrjJ2tkdy7zN_yofXUvU7iCOGdZE=jYiqX3wg@mail.gmail.com
обсуждение исходный текст
Ответы Re: Hardening PostgreSQL via (optional) ban on local file system access  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Hardening PostgreSQL via (optional) ban on local file system access  (Nathan Bossart <nathandbossart@gmail.com>)
Re: Hardening PostgreSQL via (optional) ban on local file system access  (Andres Freund <andres@anarazel.de>)
Re: Hardening PostgreSQL via (optional) ban on local file system access  (Andrey Borodin <x4mmm@yandex-team.ru>)
Re: Hardening PostgreSQL via (optional) ban on local file system access  (Jeff Davis <pgsql@j-davis.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jelte Fennema
Дата:
Сообщение: Re: [PATCH] Optimize json_lex_string by batching character copying
Следующее
От: Shawn Debnath
Дата:
Сообщение: Re: SLRUs in the main buffer pool - Page Header definitions