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 | CAKiC8XaNW47bffxU2Q2XDkFhvJBRqut0yn6LMaav2OxH0dOk5Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM ("Euler Taveira" <euler@eulerto.com>) |
| Ответы |
Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
|
| Список | pgsql-hackers |
Thanks for the feedback Euler.
On Wed, Dec 3, 2025 at 5:59 PM Euler Taveira <euler@eulerto.com> wrote:
> You are blocking one of the various ways to run malicious code using the
> postgres user. If it doesn't work the attacker will try another method. If you
> want to prevent the majority of attacks, you need to forbid COPY [ TO | FROM ],
> untrusted PLs, confine LOAD to a controlled list and/or path(s), large objects,
> user-defined functions (LANGUAGE C), some file system access functions. (Maybe I
> forgot other popular methods.) In summary, to (almost) close the gap that you
> are concerned, you have to disallow some really popular features like COPY TO. I
> don't think that's an acceptable solution. You are basically closing gap A but
> there are still gap B, C and D.
This patch is intentionally "small": it only removes the most commonly
exploited primitive (COPY PROGRAM). I agree a more comprehensive approach
would be ideal (covering extensions/untrusted PLs, LOAD, filesystem functions,
etc.), but that would take more time to design and implement properly, and was
already in my plans over the next few weekends, ideally via a single control
point. Something that flips the assumption that superuser is a trusted role,
On Wed, Dec 3, 2025 at 5:59 PM Euler Taveira <euler@eulerto.com> wrote:
> You are blocking one of the various ways to run malicious code using the
> postgres user. If it doesn't work the attacker will try another method. If you
> want to prevent the majority of attacks, you need to forbid COPY [ TO | FROM ],
> untrusted PLs, confine LOAD to a controlled list and/or path(s), large objects,
> user-defined functions (LANGUAGE C), some file system access functions. (Maybe I
> forgot other popular methods.) In summary, to (almost) close the gap that you
> are concerned, you have to disallow some really popular features like COPY TO. I
> don't think that's an acceptable solution. You are basically closing gap A but
> there are still gap B, C and D.
This patch is intentionally "small": it only removes the most commonly
exploited primitive (COPY PROGRAM). I agree a more comprehensive approach
would be ideal (covering extensions/untrusted PLs, LOAD, filesystem functions,
etc.), but that would take more time to design and implement properly, and was
already in my plans over the next few weekends, ideally via a single control
point. Something that flips the assumption that superuser is a trusted role,
and instead requires explicit enabling of potentially dangerous features.
I saw the earlier discussion about seccomp() filters, but that seemed
orthogonal to the problem of controlling what features are available to
superusers as it is.
This small step was what I put together first for my own use and to share.
I initially considered allow_copy_program as a GUC name, but went with
enable_copy_program to match other boolean GUCs like enable_nestloop,
enable_hashagg, etc. The idea is that it enables the feature when true,
instead of only allowing users to use it.
I saw the earlier discussion about seccomp() filters, but that seemed
orthogonal to the problem of controlling what features are available to
superusers as it is.
This small step was what I put together first for my own use and to share.
I initially considered allow_copy_program as a GUC name, but went with
enable_copy_program to match other boolean GUCs like enable_nestloop,
enable_hashagg, etc. The idea is that it enables the feature when true,
instead of only allowing users to use it.
I chose GUC_DISALLOW_IN_AUTO_FILE so that deploys could wire it into
postgresql.conf. GUC_DISALLOW_IN_FILE seemed too restrictive for a
control people might change later if they want to re-enable the feature
after additional system hardening. The intent was to allow conf edits
while blocking ALTER SYSTEM from a compromised superuser.
I'll make a separate patch for the typo. Thanks again.
--
Ignat Remizov
Ignat Remizov
В списке pgsql-hackers по дате отправления: