On Tue, 2022-11-08 at 01:24 +0000, Jan Bilek wrote: > I am leading PCI:SSF audit on our payment switch platform product and having a issue where our QSA > just came with multiple ways how to escalate privileges and get a shell to the remote host through > our built-in Reporting system which runs on PostgreSQL (12-14). > So these - pg_read_server_files, pg_write_server_files and pg_execute_server_program roles are > inherited from the Superuser and are also super sensitive for us, but our application user apparently > still needs to be superuser for multiple reasons. Would there be any way to go around this? Your application user doesn't need to be a superuser. > 1/ What we need is to create a postgresql user who would be pg_database_owner but not superuser ... > but apparently we still need our user to be superuser to be able to carry on with some operations > (picking one of more then few) .... > CREATE OR REPLACE LANGUAGE plpython3u; > HINT: Must be superuser to create this extension. Your application user doesn't need to create PL/Python functions. It only has to use them. If your application has to access the operating system, it has to do that in a controlled fashion: 1. through well-written SECURITY DEFINER functions that belong to a highly privileged user 2. through PL/Python functions or other untrusted language functions that are created by a superuser > 2/ Second option is to introduce some sort of limitation of allowed SQL queries and operators > for our Reporting engine, but all that white-listing / blacklisting comes with its own > problems where we are DB agnostic... That shouldn't be necessary. If your application user has restricted privileges as it should, it is automatically limited in the damage it can do. Yours, Laurenz Albe
