Date: Wed, 25 May 2022 13:49:40 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: allow building trusted languages without the untrusted versions
Message-ID: <20220525174940.GQ9030@tamriel.snowman.net>
References: <20220523165403.GC938919@nathanxps13>
 <1290329.1653326228@sss.pgh.pa.us>
 <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="gblAvmLjk8yGG9If"
Content-Disposition: inline
In-Reply-To: <20220524205841.GA1254661@nathanxps13>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20220525174940.GQ9030%40tamriel.snowman.net>
Precedence: bulk


--gblAvmLjk8yGG9If
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Nathan Bossart (nathandbossart@gmail.com) wrote:
> I guess I'd ask again whether we can do both...  We've got predefined rol=
es
> like pg_execute_server_program that allow access to COPY TO/FROM PROGRAM,
> but I have no way to categorically disable that =D1=95ort of thing if I w=
anted
> to really lock things down, even for superusers.  I'm not suggesting that
> every predefined role needs a corresponding configure option, but basic
> things like arbitrary disk/network/program access seem like reasonable
> proposals.

Locking things down "even for superuser" is something we've very
explicitly said we're not going to try and do.  Even with v1 functions,
the ability to hack around with pg_proc strikes me as almost certainly
going to provide a way for someone to gain enough control of execution
to be able to 'break out', not to mention obvious other things like
ALTER SYSTEM to change archive_command to run whatever shell commands an
attacker with superuser wants to..

> I have about 50% of a generic --disable-disk-access patch coded up which
> I'll share soon to help inform the discussion.

Do you disable the ability of superusers to use ALTER SYSTEM with this?

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.  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.

Thanks,

Stephen

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

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

iQIcBAEBCgAGBQJijmw0AAoJEO1sijiDR2RVTv4QAI1HLHINiAm2OUR9mod1TxiE
bFvCz59QNbCUdVoGdWiaLyUWVlajfgWgGflFsnLcu63EUSdeDn6QGfnV9BfuAptq
J7MdIg27zsQ84xTNAQuFCKblqxJrmXs0Tkqoz00OMeYuqr9gvImjUSq4PJokePbX
09fyJATPvm23IUNX1GMlTzhz3C32RUyP0I8EW5aW6FG7gcTNmgSlWeiEyy1BdRLc
FLuUbpMt3yfmwJjEBNGIGq82pIYG1fEYZdHQr/IZ0Vcr1L+P1BRSg0a6lstuRfk+
PoqOfy2rt8elfKNZs2xY5/SRR4pFjLgMIPBosl+YJICNHoC8AUbNVG1k+xAbR+jI
Sr90fs5ytQ95hAROG+Pyqjvx2JV/3Ls/U/h9Se0y8B+J+JK5BKArkbaIW+6JpyQe
9iEwNE7jXapIVFUR9FToc43w5/tM8lQ2czzKgp5h3YF00W8+S4E2tIeHqVFCQiqf
MbbxXuLtJQSI1a1hFeBJkYgoSZm+W7RyfMzYMzCajn2voEUEb2amZkGYwGfDZbvk
7uEYdXnStEy/PCdN8kMoSB0beqh/v6t4eWLIca/iKWizlYm8ji1sNNlHDxcQVnQc
S/4SjpqQ6zGBitmP2E6swJ0y9BcF6Vj4lBY/1d8uxxMI/1BguUInlzLBD4aDooOq
jtlWVGnEHb2rV5fJ6F5x
=YqYI
-----END PGP SIGNATURE-----

--gblAvmLjk8yGG9If--