Re: Specification for Trusted PLs? - Mailing list pgsql-hackers

From David Fetter
Subject Re: Specification for Trusted PLs?
Date
Msg-id 20100528020312.GJ3508@fetter.org
Whole thread Raw
In response to Re: Specification for Trusted PLs?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Specification for Trusted PLs?
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: [RFC] Security label support
Next
From: Fujii Masao
Date:
Subject: Re: Streaming Replication: Checkpoint_segment and wal_keep_segments on standby