Re: Specification for Trusted PLs?

David Fetter <david(at)fetter(dot)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. 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.

> 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?

If you think you can do something with this, go for it, but don't
expect me to spend any of my time on it.

regards, tom lane