Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
| От | Ignat Remizov |
|---|---|
| Тема | Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM |
| Дата | |
| Msg-id | CAKiC8XYAqAE94i41H8X0TFRsFP+EbjMZSYwxcZiMSHjr5EV13w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM (Kirill Reshke <reshkekirill@gmail.com>) |
| Ответы |
Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
|
| Список | pgsql-hackers |
On Wed, Dec 3, 2025 at 7:23 PM Kirill Reshke <reshkekirill@gmail.com> wrote:
> HI! As mentioned here and in nearby threads there is no security
> boundary there between pg superuser and os.
>
> Particularly, PGC_POSTMASTER restricts nothing, and
> GUC_DISALLOW_IN_AUTO_FILE does not prevent superuser access to
> postgresql configure file
>
> Example:
>
> ```
>
>
> db1=# show data_directory;
> data_directory
> ----------------------------------
> /home/reshke/spqrclusterdata/sh4
> (1 row)
> db1=# create table t(t text);
> CREATE TABLE
> db1=# insert into t values ('a=b');
> INSERT 0 1
> db1=# copy t to '/home/reshke/spqrclusterdata/sh4/postgresql.conf';
> COPY 1
> ```
>
> Even without COPY TO/COPY FROM feature, I believe there are no
> practical way of preventic superuser to execute arbitrary code with OS
> user privileges
Hi Kirill,
This patch does not create a hard boundary between PostgreSQL superuser and
the OS user. Making enable_copy_program PGC_POSTMASTER +
GUC_DISALLOW_IN_AUTO_FILE blocks SET/ALTER SYSTEM; flipping the GUC requires
editing postgresql.conf *and* a restart.
From your example, a superuser can indeed overwrite postgresql.conf (including
this GUC) using COPY or other mechanisms. But the attacker would then need to
also restart the service somehow.
As far as I know at present, from SQL you cannot restart the postmaster to
make the change effective.
The threat model I am trying to address is the very common "compromised
superuser password over the wire" case, where the attacker has only a SQL
connection, no shell, and no ability to restart the service.
So the patch removes the one-line RCE primitive in the scenario currently
abused by botnets.
If an attacker already has enough control to edit config files and restart the
service (or crash/restart it) or use other mechanisms, then yes, they can
regain code execution; this doesn’t sandbox the superuser. It just raises the
bar in the common case by removing COPY PROGRAM when an admin explicitly
> HI! As mentioned here and in nearby threads there is no security
> boundary there between pg superuser and os.
>
> Particularly, PGC_POSTMASTER restricts nothing, and
> GUC_DISALLOW_IN_AUTO_FILE does not prevent superuser access to
> postgresql configure file
>
> Example:
>
> ```
>
>
> db1=# show data_directory;
> data_directory
> ----------------------------------
> /home/reshke/spqrclusterdata/sh4
> (1 row)
> db1=# create table t(t text);
> CREATE TABLE
> db1=# insert into t values ('a=b');
> INSERT 0 1
> db1=# copy t to '/home/reshke/spqrclusterdata/sh4/postgresql.conf';
> COPY 1
> ```
>
> Even without COPY TO/COPY FROM feature, I believe there are no
> practical way of preventic superuser to execute arbitrary code with OS
> user privileges
Hi Kirill,
This patch does not create a hard boundary between PostgreSQL superuser and
the OS user. Making enable_copy_program PGC_POSTMASTER +
GUC_DISALLOW_IN_AUTO_FILE blocks SET/ALTER SYSTEM; flipping the GUC requires
editing postgresql.conf *and* a restart.
From your example, a superuser can indeed overwrite postgresql.conf (including
this GUC) using COPY or other mechanisms. But the attacker would then need to
also restart the service somehow.
As far as I know at present, from SQL you cannot restart the postmaster to
make the change effective.
The threat model I am trying to address is the very common "compromised
superuser password over the wire" case, where the attacker has only a SQL
connection, no shell, and no ability to restart the service.
So the patch removes the one-line RCE primitive in the scenario currently
abused by botnets.
If an attacker already has enough control to edit config files and restart the
service (or crash/restart it) or use other mechanisms, then yes, they can
regain code execution; this doesn’t sandbox the superuser. It just raises the
bar in the common case by removing COPY PROGRAM when an admin explicitly
disables it.
If the consensus ends up being that we should instead design a more general
"dangerous features" control (covering all breakout paths) behind a single
switch, I would happily work on that in my free time. This patch is just a
small, concrete step in that direction that I already had working.
--
Ignat Remizov
If the consensus ends up being that we should instead design a more general
"dangerous features" control (covering all breakout paths) behind a single
switch, I would happily work on that in my free time. This patch is just a
small, concrete step in that direction that I already had working.
--
Ignat Remizov
В списке pgsql-hackers по дате отправления: