Re: Possibility to disable `ALTER SYSTEM` - Mailing list pgsql-hackers

On Wed, Jan 31, 2024 at 12:28 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> You cannot enforce such restrictions within Postgres.
> It has to be done by an outside mechanism.  If you think
> different, you are mistaken.

It seems like the biggest reason why we can't enforce such
restrictions with Postgres is that you won't hear of anyone committing
any code which would let us enforce such restrictions in Postgres. I'm
not saying that there's no other problem here, but you're just digging
in your heels. I wrote upthread "We can't resolve the tension between
those two things in either direction by somebody hammering on the side
of the argument that they believe to be correct and ignoring the other
one" and you replied to that by quoting what I said about the side of
the argument that you believe and hammering on it some more. I really
wish you wouldn't do stuff like that.

One thing that I think might be helpful here is to address the
question of exactly how the superuser can get general-purpose
filesystem access. They can definitely do it if there are any
untrusted PLs installed, but the person who configures the machine can
control that. They can also do it if extensions like adminpack are
available, but the server administrator can control that, too. They
can do it through COPY TO/FROM PROGRAM, but we could provide a way to
restrict that, and I think an awful lot of people want that. I don't
know of any other "normal" way of getting filesystem access, but the
superuser can also hack the system catalogs. That means they can
create a function definition that tries to run an arbitrary function
either in PostgreSQL itself or any .so they can get their hands on --
but this is a much less powerful technique since
5ded4bd21403e143dd3eb66b92d52732fdac1945 removed the version 0 calling
convention. You can no longer manufacture calls to random C functions
that aren't expecting to be called from SQL. The superuser can also
arrange to call a function that *is* intended to be SQL-callable with
the wrong argument types. It's not hard to manufacture a crash that
way, because if you call a function that's expecting a varlena with an
integer, you can induce the function to read more memory than intended
and run right off the stack. I'm not quite sure whether this can be
parlayed into arbitrary code execution; I think it's possible.

And, then, of course, you can use ALTER SYSTEM to set archive_command
or restore_command or similar to a shell command of your choosing.

What else is there? We should actually document the whole list of ways
that a superuser can escape the sandbox. Because right now there are
tons of people, even experienced PG users, who think that superusers
can't escape from PG at all, or that it's just about COPY TO/FROM
PROGRAM. The lack of clarity about what the issues are makes
intelligent discussion difficult. Our documentation hints at the fact
that there's no privilege boundary between the superuser and the OS
user, but it's not very clear or very detailed or in any very central
place, and it's not surprising that not everyone understands the
situation correctly.

At any rate, unless there are way more ways to get filesystem access
than what I've listed here, it's not unreasonable for people to want
to shut off the most obvious ones, like COPY TO/FROM PROGRAM and ALTER
SYSTEM. And there's no real reason we can't provide a way to do that.
It's just sticking your head in the stand to say "well, because we
can't prevent people from crafting a stack overrun attack to access
the filesystem, we shouldn't have a feature that tells them ALTER
SYSTEM is disabled on this instance."

--
Robert Haas
EDB: http://www.enterprisedb.com