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@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 <tgl@sss.pgh.pa.us> wrote:
> >> > > Robert Haas <robertmhaas@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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@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