Date: Wed, 25 May 2022 16:07:17 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: allow building trusted languages without the untrusted versions
Message-ID: <20220525200717.GR9030@tamriel.snowman.net>
References: 
 <CA+TgmoY-Xy_ObfYVUTSamD8BmW8npaktbr65JtnkW-c1VQobVA@mail.gmail.com>
 <1333860.1653338790@sss.pgh.pa.us>
 <CA+TgmoYZKLxftaZZvj4_-zHQ27CBeUs+KvggyU3qS79-7aQEPA@mail.gmail.com>
 <1354561.1653345768@sss.pgh.pa.us>
 <CA+TgmoZ_c0j4ut87_QCFm697Qq5Z_u66VZt2PYenfZVjUT1qRA@mail.gmail.com>
 <20220524172851.GA1191690@nathanxps13>
 <CA+TgmobOQiDXpYq6TgaCzH3p5c0Fko-wXqCjgd5YsR6RsX31vA@mail.gmail.com>
 <20220524205841.GA1254661@nathanxps13>
 <20220525174940.GQ9030@tamriel.snowman.net>
 <1978948.1653503311@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="/Isdj7O9hWi8F9Bn"
Content-Disposition: inline
In-Reply-To: <1978948.1653503311@sss.pgh.pa.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20220525200717.GR9030%40tamriel.snowman.net>
Precedence: bulk


--/Isdj7O9hWi8F9Bn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I really don't think this is going to be anywhere near as
> > straight-forward as it might appear to be to prevent a superuser from
> > being able to break out of PG.
>=20
> This gets back to the point I made before about it not being worthwhile
> to implement half-measures.  There is a whole lot of history and code
> details associated with the presumption that superuser gives you OS
> access, and I'm certainly prepared to believe that turning that off
> is a fool's errand.

Right.

> Perhaps a better answer for providers who need something like this
> is to sandbox the Postgres server using OS-provided facilities.

I'm guessing they wouldn't feel that to be a very satisfactory answer
but if they want to give people PG superuser access then that does seem
like an approach which at least might be able to work.

> > Instead, we should be moving in the
> > direction of making it so that there doesn't need to be a superuser
> > that's ever logged into except under serious emergency situations where
> > the system is built to require multi-person access to do so.
>=20
> I'm a little skeptical that our present design direction really moves
> the needle very far in this area.  We've sliced and diced superuser
> aplenty, but that doesn't make individual capabilities such as
> pg_write_all_data or ALTER SYSTEM any less dangerous from the standpoint
> of someone trying to prevent breaking out.

I'm guessing you're referring to pg_write_server_files here, not
pg_write_all_data (as the latter should generally be 'safe' in these
terms?  If not, would be good to understand the concern there).

I don't think that what they're actually looking for is a way to give a
user access to pg_write_server_files or to ALTER SYSTEM though- and what
we have today explicitly allows them to GRANT out lots of rights to
non-superusers without also giving those users access to
pg_write_all_data and ALTER SYSTEM and that's basically the point.

Allowing non-superusers to create extensions which have C functions is
one example of moving in this direction of allowing the 'typical DBA'
things to be done by non-superusers.  There's certainly a lot more that
we can do in that direction.

Allowing users to create other users without being a superuser or
effectively being able to gain superuser access strikes me as the next
big step in that same direction of splitting up what only superusers are
able to do today.  That's what the recent discussion about CREATEROLE
was really all about, just figuring out how to allow CREATEROLE and some
level of control over those roles after they've been created (and by
whom).

What isn't terribly clear to me is how what started this particular
thread is moving things in that direction though, instead it seems to be
trying to go in the direction of having a system where superuser could
be "safely" given out and I am concerned about the project trying to
provide a way to guarantee that based on some configure switches.  That
strikes me as unlikely to end up being successful and might also make it
so that even a superuser isn't able to do what a superuser needs to be
able to to do- and then do we need a super superuser..?

The very specific "it'd be nice to build PG w/o having untrusted
languages compiled in" is at least reasonably clearly contained and
reasonable to see if we are, in fact, doing what we claim we're doing
with such a switch.  A switch that's "--disable-disk-access" seems to
be basically impossible for it to *really* do what a simple reading of
the option implies (clearly we're going to access the disk..) and even
if we try to say "well, not direct disk access" then does that need to
disable ALTER SYSTEM (or just for certain GUCs..?) along with things
like pg_write_server_files and pg_execute_server_programs, and probably
modifying pg_proc and maybe modification of the other PG catalogs?  But
then, what if you actually need to modify pg_proc due to what we say to
do in release notes or for other reasons?  Would you have to replace the
PG binaries to do so?  That doesn't strike me as particularly
reasonable.

Thanks,

Stephen

--/Isdj7O9hWi8F9Bn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJijox1AAoJEO1sijiDR2RVF7IQALm9y5E7m6F4Vgr5X9p3SczC
ZWQCWEqQ2gmIh1HFy28ZlzWGYGbbKpYucWHUXH+wx9m6LJyQHBShmrzwcYD8kDBJ
OqvooufRgQwA9TwmwbJ/61AL1fQyocxovER5J0LSTxNriwjIYg3cb3609ONP9XtF
ct3Y5MNmvwuSuY81RaFRZkWRuLtw4mKBamNbFVnCy1jFTi5HWH9zUb7GVXD4JhzO
Ume0Bm4IAMInw6m2eVLLpSBNow4J0sqoAWmMOeHtz3+ooGvjoD0atgGGZ8xmtot1
5hvChn2rZ57KGG79PyGIQXBE3u9ly4F27LPkyM1dmEmlbUdeS02ZPR2/Py62gB5O
OeH22hQ+CD1+4QvKRlSLwIfAOGPQuCONpmlPAhFRdgiC7sgrF3ym/BS2AZRMlXpK
Dl3W+zIHJl2n0RNO1aZzX1MKLFjZjxlwKc0i2VyyA6gTH0vbDtpnZe/Ek/B6IHwS
wfOc9DOaPybTIZODUADJXKOUSYvf0kTv6ICO3iOopocv5mJ01nrspG9G1KhxWMh7
bnWD+/bMLu3/trSRROtj1ATTtNH/JH8f2M72JiocWSOI1WP5krxG4Glcd0eE0jbF
+qD4tL2/qPI8WLlwYHyZ6/r3Zv/uZy83i4I+HJzfWwTq4oaS7YoM66n+fmd8hTBZ
pu4VuBz/h8EqYT5nW55v
=ZJfF
-----END PGP SIGNATURE-----

--/Isdj7O9hWi8F9Bn--