Re: Hardening PostgreSQL via (optional) ban on local file system access
От | Hannu Krosing |
---|---|
Тема | Re: Hardening PostgreSQL via (optional) ban on local file system access |
Дата | |
Msg-id | CAMT0RQTxZE7nGye2SJR=xt6THagEJJDWv8qq9+0HAx86uubCbg@mail.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
Re: Hardening PostgreSQL via (optional) ban on local file system access |
Список | pgsql-hackers |
On Sat, Jun 25, 2022 at 1:13 AM Andres Freund <andres@anarazel.de> wrote: > > 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. Are you claiming that one can manipulate PostgreSQL to do any file writes directly by manipulating pg_proc to call the functions "in a wrong way" ? My impression was that this was largely fixed via disabling the old direct file calling convention, but then again I did not pay much attention at that time :) So your suggestion would be to also include disabling access to at least pg_proc for creating C and internal functions and possibly some other system tables to remove this threat ? Cheers Hannu
В списке pgsql-hackers по дате отправления: