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 | CAKiC8XaNUXHGz0EAh4_FXwmPzW59CdFS6KgOGs1Kc81-UkWwvg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes:
> Adding a feature which allows a system to run with compromisable
> superuser credentials doesn't seem like something the community
> usually accepts.
Ashutosh,
I think there’s a misunderstanding. This doesn’t "allow" running with weak
superuser creds; it’s a hardening toggle for admins who already recognize
the risk and want to remove one of the easiest RCE primitives if superuser
does get compromised. Superuser remains fully trusted; the default stays on
to preserve behavior and is fully backwards compatible. When an operator
explicitly sets it to off and restarts, COPY … PROGRAM is blocked even for
superuser, reducing blast radius in misconfigured/legacy environments (e.g.,
weak/default creds on shared exposed dev/staging stacks).
The intent is defense-in-depth, not to encourage running with compromisable
> Adding a feature which allows a system to run with compromisable
> superuser credentials doesn't seem like something the community
> usually accepts.
Ashutosh,
I think there’s a misunderstanding. This doesn’t "allow" running with weak
superuser creds; it’s a hardening toggle for admins who already recognize
the risk and want to remove one of the easiest RCE primitives if superuser
does get compromised. Superuser remains fully trusted; the default stays on
to preserve behavior and is fully backwards compatible. When an operator
explicitly sets it to off and restarts, COPY … PROGRAM is blocked even for
superuser, reducing blast radius in misconfigured/legacy environments (e.g.,
weak/default creds on shared exposed dev/staging stacks).
The intent is defense-in-depth, not to encourage running with compromisable
credentials.
Tom Lane <tgl@sss.pgh.pa.us> writes:
> This argument is nonsense, because if you've got superuser you can
> just change the GUC's setting again. Not to mention all the *other*
> ways that a superuser can break out to the OS level. I don't think
> this proposal adds anything except more complication, which is not
> a good attribute for security-critical considerations.
Tom,
A quick clarification: enable_copy_program is PGC_POSTMASTER and
GUC_DISALLOW_IN_AUTO_FILE. SET/ALTER SYSTEM both error (I added regression
tests), and a reload call won’t change it. The only way to flip it is to edit
postgresql.conf (or startup params) and restart. So a compromised superuser
session cannot just turn it back on.
I agree it doesn’t sandbox superuser or block other breakout paths; the intent
is narrowly to remove the most commonly exploited RCE primitive (COPY PROGRAM)
when an admin explicitly opts out. Default remains on to preserve behavior.
--
Tom Lane <tgl@sss.pgh.pa.us> writes:
> This argument is nonsense, because if you've got superuser you can
> just change the GUC's setting again. Not to mention all the *other*
> ways that a superuser can break out to the OS level. I don't think
> this proposal adds anything except more complication, which is not
> a good attribute for security-critical considerations.
Tom,
A quick clarification: enable_copy_program is PGC_POSTMASTER and
GUC_DISALLOW_IN_AUTO_FILE. SET/ALTER SYSTEM both error (I added regression
tests), and a reload call won’t change it. The only way to flip it is to edit
postgresql.conf (or startup params) and restart. So a compromised superuser
session cannot just turn it back on.
I agree it doesn’t sandbox superuser or block other breakout paths; the intent
is narrowly to remove the most commonly exploited RCE primitive (COPY PROGRAM)
when an admin explicitly opts out. Default remains on to preserve behavior.
--
Ignat Remizov
В списке pgsql-hackers по дате отправления: