On Thu, May 27, 2010 at 09:51:30PM -0400, Robert Haas wrote: > On Thu, May 27, 2010 at 7:10 PM, David Fetter <da...@fetter.org> wrote: > > On Fri, May 28, 2010 at 01:03:15AM +0300, Peter Eisentraut wrote: > >> On fre, 2010-05-21 at 14:22 -0400, Robert Haas wrote: > >> > On Fri, May 21, 2010 at 2:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> > > Robert Haas <robertmh...@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. > >> > >> Succinctly: A trusted language does not grant access to data that > >> the user would otherwise not have. > > > > That's a great definition from a point of view of understanding by > > human beings. A whitelist system will work better from the point > > of automating tests which, while they couldn't conclusively prove > > that something was actually this way, could go a long way toward > > making sure that PLs didn't regress into untrusted territory. > > You haven't presented any sort of plan for how such automated > testing would actually work. Perhaps if you presented the plan > first we could think about how to provide for its needs. I'm > generally of the opinion that it's not possible to do automated > testing for security vulnerabilities (beyond crash testing, perhaps) > but if you have a good idea let's talk about it.
I don't know about a *good* idea, but here's the one I've got. 1. Make a whitelist. This is what needs to work in order for a language to be a fully functional trusted PL. 2. Write tests that check that each thing on the whitelist works as advertised. These are language specific. 3. (the un-fun part) Write tests which attempt to do things not in the whitelist. We can start from the vulnerabilities so far discovered. 4. Each time a vulnerability is discovered in one language, write something that tests for it in the other languages. I get that this isn't going to ensure that the access control is perfect. It's more a backstop against regressions of previously function access controls. Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers