From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Hannu Krosing <hannuk(at)google(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Robert Pang <robertpang(at)google(dot)com> |
Subject: | Re: Hardening PostgreSQL via (optional) ban on local file system access |
Date: | 2022-06-27 20:37:49 |
Message-ID: | f5522e2d1be5c7fdc21fe8c77186b1208882f5e7.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2022-06-27 21:36:53 | Re: Hardening PostgreSQL via (optional) ban on local file system access |
Previous Message | Peter Geoghegan | 2022-06-27 20:36:36 | Re: do only critical work during single-user vacuum? |