Re: Specification for Trusted PLs?

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: David Fetter <david(at)fetter(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Specification for Trusted PLs?
Date: 2010-05-24 03:16:58
Message-ID: 4BF9EFAA.6080008@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22/05/10 02:12, Robert Haas wrote:
> On Fri, May 21, 2010 at 1:58 PM, David Fetter<david(at)fetter(dot)org> wrote:
>> On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:
>>> * David Fetter (david(at)fetter(dot)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?

Personally, I don't think a PL should be trusted unless it _does_ define
a whitelist of operations. Experience in the wider world has shown that
this is the only approach that works. Regression testing to make sure
all possible approaches to access unsafe features are blocked is doomed
to have holes where there's another approach that hasn't been thought of
yet.

Perl's new approach is whitelist based. Python restricted mode failed
not least because it was a blacklist and people kept on finding ways
around it. Lua and JavaScript are great examples of whitelist
approaches, where the language just doesn't expose features that're
dangerous - in fact, the core language doesn't even *have* those
features. PL/PgSQL is the same, and works well as a trusted language for
that reason.

Java's SecurityManager is whitelist based (allowed classes, allowed
operations), and has proved very secure.

--
Craig Ringer

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2010-05-24 03:19:31 Re: Specification for Trusted PLs?
Previous Message Jan Wieck 2010-05-24 02:45:35 Re: Specification for Trusted PLs?