Creating a capabilities-based restricted execution system

[Serge Orlov]

"Sean R. Lynch" <seanl at chaosring.org> wrote in message news:srudnTjvU9BOH2qiRVn-uA at speakeasy.net...
> Ok, I think you've pretty much convinced me here. My choices for
> protected attributes were to either name them specially and only allow
> those attribute accesses on the name "self" (which I treat specially),
> or to make everything protected by default, pass all attribute access
> through a checker function (which I was hoping to avoid), and check for
> a special attribute to define which attributes are supposed to be
> public. Do you think it's good enough to make all attributes protected
> as opposed to private by default?

Are you talking about C++ like protected fields and methods? What if
untrusted code subclasses your proxy object?

> > I'm not sure how to deal with str.encode too. You don't know what
> > kind of codecs are registered for that method for sure, one day there
> > could be registered an unknown codec that does something unknown.
> > Shouldn't you have two (or several) codecs.py modules(instances?)
> > for trusted and untrusted code? And str.encode should be transparently
> > redirected to the proper one?
>
> I guess I'll just make attributes protected by default, and force the
> programmer to go out of their way to make things public. Then I can use
> the Zope/RestrictedPython technique of assuming everything is insecure
> until proven otherwise, and only expose parts of the interface on
> built-in types that have been audited.

Thinking about str.encode I conviced myself that global state shouldn't
be shared by different security domains so that means codecs.py and
__builtins__ must be imported into each security domain separately.
It's pretty easy to do with codecs.py since it's python code. But importing
__builtins__ more than once is pretty hard since it wasn't designed
for that.

-- Serge.