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 <pgsql@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
>
>