My current thinking is (based on more insights from Andres) that we should also have a startup flag to disable superuser altogether to avoid bypasses via direct manipulation of pg_proc.
Experience shows that 99% of the time one can run PostgreSQL just fine without a superuser, so having a superuser available all the time is kind of like leaving a loaded gun on the kitchen table because you sometimes need to go hunting. I am especially waiting for Andres' feedback on viability this approach. Cheers Hannu On Mon, Jun 27, 2022 at 10:37 PM Jeff Davis <pg...@j-davis.com> wrote: > > On Sat, 2022-06-25 at 00:08 +0200, Hannu Krosing wrote: > > 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. > > How much of this can be done as a special extension already? > > For instance, a ProcessUtility_hook can prevent superuser from > executing COPY TO/FROM PROGRAM. > > As others point out, that would still leave a lot of surface area for > attacks, e.g. by manipulating the catalog. But it could be a starting > place to make attacks "harder", without core postgres needing to make > security promises that will be hard to keep. > > Regards, > Jeff Davis > >
