Creating a capabilities-based restricted execution system

[Sean R. Lynch]

Serge Orlov wrote:
> You're right, the wording is not quite correct. My point was that it should
> take effort to make attributes _public_, for example, going to another
> source line and typing attribute name or doing whatever "declaration" means.
> This way adding new attribute or leaking "unsecured" object will
> raise an exception when untrusted code will try to access it. Otherwise
> one day something similar to rexec failure will happen: somebody
> added __class__ and __subclasses__ attributes and rexec blindly
> allowed to access them. The leading underscore doesn't matter, it
> could be name like encode/decode that is troublesome.
> 
> By the way, my code above is buggy, it's a good idea that you're
> not going to use it :) Let me try it the second time in English words:
> If the attribute 'attr' is declared public give it. If the function with
> UUID has access to attribute 'attr' on object 'obj' give it. Otherwise fail.

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?

> Nevermind, it's just a scary word :) It can concern you if you worry
> about information leaking from one security domain to another. Like
> prisoners knocking the wall to pass information between them. In
> computers it may look like two plugins, one is processing credit
> cards and the other one has capability to make network connections.
> If they are written by one evil programmer the first one can "knock
> the wall" to pass the information to the second. "knocking the wall"
> can be encoded like quick memory allocation up to failure = 1, no
> quick memory allocation = 0. Add error correction and check summing
> and you've got a reliable leak channel.

Hmmm, I think this would be even more difficult to protect from than 
doing resource checks. Fortunately, I'm not planning on processing any 
credit cards with this code. The primary purpose is so that multiple 
programmers (possibly thousands) can work in the same memory space 
without stepping on one another.

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

Thank you very much for your extremely informative responses!