Re: Specification for Trusted PLs?

On Thu, May 27, 2010 at 09:51:30PM -0400, Robert Haas wrote:
> On Thu, May 27, 2010 at 7:10 PM, David Fetter <david(at)fetter(dot)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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> > > Robert Haas <robertmhaas(at)gmail(dot)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 <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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