Date: Mon, 23 May 2022 19:09:03 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Nathan Bossart <nathandbossart@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: allow building trusted languages without the untrusted versions
Message-ID: <20220523230903.GP9030@tamriel.snowman.net>
References: <20220520225619.GA876272@nathanxps13>
 <571753.1653092411@sss.pgh.pa.us>
 <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="lx6+J6gHrzwEpYNy"
Content-Disposition: inline
In-Reply-To: <1354561.1653345768@sss.pgh.pa.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20220523230903.GP9030%40tamriel.snowman.net>
Precedence: bulk


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

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > It's not just a question of whether it was meant to be SQL-callable --
> > it's also a question of what arguments it was expecting to be called
> > with. At the very least, you can cause the server to core dump if you
> > pass something that isn't a valid pointer to a function that is
> > expecting a pointer, which is something a CSP very likely does not
> > want a customer to be able to do. I think, however, that there's every
> > possibility that you can create more havoc than that. You can
> > basically call a function that's expecting a pointer with a pointer to
> > anything you can find or guess the memory address of. Maybe that's not
> > enough control to cause anything worse than a server crash, but I sure
> > wouldn't bet on it. There's a lot of functions floating around, and if
> > none of them can be tricked into doing filesystem access today, well
> > someone might add a new one tomorrow.
>=20
> [ shrug... ]  So is your point that we shouldn't bother to do anything?
> I don't personally have a problem with leaving things where they stand
> in this area.  However, if we're going to do something, I think at
> minimum it should involve blocking off everything we can identify as
> straightforward reproducible methods to get disk access.

I have a hard time seeing the value in allowing catalog hacking, even
for a cloud provider, and making sure to cut off all possible ways that
could be abused strikes me as unlikely to be successful.

Instead, I'd argue that we should be continuing to work in the direction
of splitting up what can only be done by a superuser today using
predefined roles and other methods along those lines.  How that lines up
with this latest ask around untrusted languages is something I'm not
exactly sure about, but a magic configure option that is
"--don't-allow-what-AWS-doesn't-want-to-allow" certainly doesn't seem
like it's going in the right direction (and, no, not every cloud
provider is going to want the exact same thing when it comes to whatever
this option is that we're talking about, so we'd end up having to have
configure options for each if we start going down this road...).

I agree with the general idea of "has all of today's superuser rights
except the ability to hack catalogs or do disk access" being one
use-case we should be thinking about, along with "also can't do network
access" and "allowed to do network or disk access but can't directly
hack up the catalog", but I don't see us growing configure options for
all these things and would much rather we have a way to let folks
configure their systems along these different lines, ideally without
having to make that decision at build time.

Thanks,

Stephen

--lx6+J6gHrzwEpYNy
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIcBAEBCgAGBQJijBQOAAoJEO1sijiDR2RVg0cP/1AVun65ZC8h9qpV8r77mSM5
2LKZjVN12/HklpSAlNrqyc27W0p4R8PdlJ+Dgdj4YEO6yCMfH95BbOohCoJcp1C2
aDt4I0DXI5zeXw+dVFn60RpFgWNAmOmzYl6o6uDiLHDblsM4G775oF1sl/f5byh0
sHOlNbmnbg8Jb3irho+Ken3GRN0bHVw3ehcH9aW/2GDoOuUcCrb0btPrU6XGfDMm
hdP9L4nN00N5ZzkOOfbOyrtEhGoqdzsRbDcfh5NAo2aS16CWC5nV90tFPFYHGhD6
Qr2SDLHous45l1dFPdU0WoTy5bZmExbHnZeFJHROR0IjU6VJ9P0q4hlHvclhi/up
HF2j5K0F/6JsvVMmJRCTaVahFft1PisunW7ohxfZp9z3Px1FJzu4SoIXzhN339Sd
lsWQpZWk3za7kfFIQLGKvzu9nzCE7atT4hYUX156UMfRODhnTa2cL5kkYeM2AbwY
MYDhUXkwN60g/z718Sr1uMwAk9gjniG4LZSk8LyfxvbsSQvoQaDWyVQKTG8bw3PB
aKfrsggkgqzW1w1rgCmDBA5+zXayjPXARXYehSGj+rCDiNoLY5O0T0kxVoATjn+Q
YcxyqWKeblyn622j6WoxJ3XdPTyYtYMTbt98vCRbgsTtN83DH5JE/iGWntdRGvOP
hmdbLe0b0O7CFXXNVHV0
=4mnj
-----END PGP SIGNATURE-----

--lx6+J6gHrzwEpYNy--