On Mon, May 23, 2022 at 1:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> There would probably be some interest in a "--disable-disk-access"
> configure option that did all of this stuff (and some more things
> too), with the aim of locking down *all* known paths to filesystem
> access. I don't see much value in retail options that do some of that.
> In fact, what they might mostly accomplish is to give people a false
> sense of security.
I definitely think there's a need for a user who can manipulate
objects in the database much like a superuser (i.e. access all
objects, grant and revoke all privileges, etc.) but who can't break
out into the OS user account and assume it's privileges. I'm not sure
whether it's best to try to get there by creating a mode where the
superuser's privileges are trimmed back, or to get there by still
having a super-user who is just as super as at present but then also
have the ability to create other users who are not superusers but have
many of the same privileges with respect to in-database objects.
It seems to me that you've got to think not only about vectors for
executing arbitrary C code and/or shell commands, but also the
superuser's power to mess with the catalogs. If you can UPDATE
pg_proc, you can certainly hack the system, I think. But that isn't
really implied by --disable-disk-access, which makes me think that's
not really the right way of thinking about it. In my mind, it's
reasonable as a matter of security policy to decide that you don't
ever want plperlu on your system, only plperl. And it's reasonable to
decide whether or not you also need some kind of restricted super-user
facility. They're just two different issues.
--
Robert Haas
EDB: http://www.enterprisedb.com