Creating a capabilities-based restricted execution system

[Sean R. Lynch]

Serge Orlov wrote:
> "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?

Hmmm. I was thinking you'd trust those you were allowing to subclass 
your classes a bit more than you'd trust people to whom you'd only give 
instances, but now that you mention it, you're right. I should make all 
attributes fully private by default, requiring the progammer to declare 
both protected and public attributes, and I should make attributes only 
writable by the class on which they're declared. I guess I also need to 
make it impossible to override any attribute unless it's declared OK to 
do so.

I wonder if each of these things can be done with capabilities? A 
reference to a class is basically the capability to subclass it. I could 
create a concept of "slots" as well. This would require a change in 
syntax, however; you'd be calling setter(obj, value) and getter(obj), 
and this isn't really something I could cover up in the compiler. I 
think I'll forget about this for now because E just uses Java's own 
object encapsulation, so I guess I should just stick with creating 
Java-like object encapsulation in Python.

I need to implement a callsuper() function as well, because I don't want 
to be giving programmers access to unbound methods.

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

Global *mutable* state shouldn't be shared, AFAICT. I believing making 
sure no mutable state is reachable through __builtins__ and having a new 
globals dict for each security domain should be enough. Any modules that 
are imported would need to be imported separately for each domain, which 
should be possible with a modified __import__ builtin. I don't have any 
intention of allowing import of unaudited C modules.