Creating a capabilities-based restricted execution system

[Sean R. Lynch]

I've been playing around with Zope's RestrictedPython, and I think I'm 
on the way to making the modifications necessary to create a 
capabilities-based restricted execution system. The idea is to strip out 
any part of RestrictedPython that's not necessary for doing capabilities 
and do all security using just capabilities.

The basic idea behind capabilities is that you don't give any piece of 
code you don't trust a reference to something you don't want it to have 
access to. You use proxies instead (E calls them "facets").

In order to be able to allow untrusted code to create proxy objects, I 
needed to be able to store a reference to the proxied object in a 
private attribute.

To create private attributes, I'm using "name mangling," where names 
beginning with X_ within a class definition get changed to 
_<uuid>_<name>, where the UUID is the same for that class. The UUIDs 
don't need to be secure because it's not actually possible to create 
your own name starting with an underscore in RestrictedPython; they just 
need to be unique across all compiler invocations.

The nice thing about using this name mangling is that it's only done at 
compile time and doesn't affect runtime performance. An interesting side 
effect is that code defined on a class can access private attributes on 
all descendants of that class, but only ones that are defined by other 
code on that class, so this isn't a security issue.

I was thinking I needed read-only attributes to be able to avoid 
untrusted code's being able to sabotage the revoke method on a proxy 
object, but I'm thinking that just keeping around a reference to the 
revoke method in the original code may be enough.

Does anyone think I'm going in completely the wrong direction here? Am I 
missing anything obvious?