Creating a capabilities-based restricted execution system
Sean R. Lynch
seanl at chaosring.org
Mon Jan 5 00:05:10 CET 2004
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
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.
More information about the Python-list