On Fri, Jun 24, 2022 at 4:13 PM 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.
Using only psql connected by the postgres role, without touching the filesystem to bootstrap your attack, how would this be done? If you specify CREATE FUNCTION ... LANGUAGE c you have to supply filename references, not a code body and you won't have been able to put that code on the server.
We should be capable of having the core server be inescapable to the filesystem for a superuser logged in remotely. All such access they can do with the filesystem would be mediated by controlled code/APIs.
C-based extensions would be an issue without a solution that does provide an inescapable sandbox aside from going through our API. Which I suspect is basically impossible given our forked process driven execution model.
