Specification for Trusted PLs?
in [PgSql]
|
From: Robert Haas on 21 May 2010 14:12 On Fri, May 21, 2010 at 1:58 PM, David Fetter <david(a)fetter.org> wrote: > On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote: >> * David Fetter (david(a)fetter.org) wrote: >> > That is *precisely* the business we need to be in, at least for the >> > languages we ship, and it would behoove us to test languages we don't >> > ship so we can warn people when they don't pass. >> >> k, let's start with something simpler first tho- I'm sure we can pull in >> the glibc regression tests and run them too. You know, just in case >> there's a bug there, somewhere. > > That's pretty pure straw man argument. I expect much higher quality > trolling. D-. I'm sorely tempted to try to provide some higher-quality trolling, but in all seriousness I think that (1) we could certainly use much better regression tests in many areas of which this is one and (2) it will never be possible to catch all security bugs - in particular - via regression testing because they typically stem from cases people didn't consider. So... can we get back to coming up with a reasonable definition, and if somebody wants to write some regression tests, all the better? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 21 May 2010 14:21 Robert Haas <robertmhaas(a)gmail.com> writes: > So... can we get back to coming up with a reasonable > definition, (1) no access to system calls (including file and network I/O) (2) no access to process memory, other than variables defined within the PL. What else? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 21 May 2010 14:22 On Fri, May 21, 2010 at 2:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> So... can we get back to coming up with a reasonable >> definition, > > (1) no access to system calls (including file and network I/O) > > (2) no access to process memory, other than variables defined within the > PL. > > What else? Doesn't subvert the general PostgreSQL security mechanisms? Not sure how to formulate that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Greg Sabino Mullane" on 21 May 2010 14:53 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > Well, the best way to define what a trusted language can do is to > define a *whitelist* of what it can do, not a blacklist of what it > can't do. That's the only way to get a complete definition. It's then > up to the implementation step to figure out how to represent that in > the form of tests. No, that's exactly backwards. We can't define all the things a language can do, but we can certainly lay out the things that it is not supposed to. - -- Greg Sabino Mullane greg(a)turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201005211452 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkv21oIACgkQvJuQZxSWSsg8lQCdFKNXO5XWD5bJ0lQAx3prFYGW 5CYAnjHiuwKVAxvwjl/clyiwCtXCVvr0 =5tSD -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stephen Frost on 21 May 2010 14:57
* Robert Haas (robertmhaas(a)gmail.com) wrote: > So... can we get back to coming up with a reasonable > definition, and Guess I'm wondering if we could steal such a definition from one of the languages we allow as trusted already.. Just a thought. I certainly think we should make sure that we document how untrusted languages are handled from the PG point of view (eg: can't change ownership). > if somebody wants to write some regression tests, all > the better? I certainly am fine with that to the extent that they want to work on that instead of hacking PG.. Guess I just don't think it should be a priority for us to come up with a signifigant regression suite for pieces that are supposedly being externally managed. Thanks, Stephen |