On Thu, May 27, 2010 at 11:09:26PM -0400, Tom Lane wrote:
> David Fetter <david@fetter.org> writes:
> > 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.
>
> Well, I pretty much lose interest right here, because this is already
> assuming that every potentially trusted PL is isomorphic in its
> capabilities.
That's not normally a problem. The conventional way would be to place
the interpreter in its own sandbox, similar to how Chrome has each tab
running in its own process. These processes are protected in a way
so that the code running inside them can't do any harm--e.g. a ptrace
jail[1]. This is quite a change from existing pl implementations, and
present a different set of performance/compatibility issues.
> If that were so, there'd not be very much point in
> supporting multiple PLs. A good example here is R. I have no idea
> whether PL/R is trusted or trustworthy, but in any case the main point
> of supporting that PL is to allow access to the R statistical library.
> How does that fit into a whitelist designed for some other language?
> It doesn't.
AFAIU, a trusted language should only be able to perform computation,
e.g. not touch the local filesystem, beyond readonly access to library
code, and not see the network. Policies such as these are easy to
enforce in a ptrace jail, and would still allow a trusted pl/r to do
whatever it wants to get any pure calculation done. As soon as it needs
to touch the file system the language becomes non-trusted.
> > 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.
>
> And here is the *other* fatal problem: a whitelist does not in fact give
> any leverage at all for testing whether there is access to functionality
> outside the whitelist. (It might be useful if you could enforce the
> whitelist at some sufficiently low level of the language implementation,
> but as a matter of testing, it does nothing for you.) What you're
> suggesting isn't so much un-fun as un-possible. Given a maze of twisty
> little subroutines all different, how will you find out if any of them
> contain calls of unwanted functionality?
A jail helps with a lot of this; the remainder is in the normal fact
that bug testing can only demonstrate the presence of bugs and you need
to do formal code proof to check for the absence of bugs.
-- Sam http://samason.me.uk/[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.122.5494