Creating a capabilities-based restricted execution system

Sean R. Lynch seanl at
Mon Jan 5 05:54:30 CET 2004

Serge Orlov wrote:
> "Sean R. Lynch" <seanl at> wrote in message news:mvScnSDrma66AWWiXTWc-g at
>>Global *mutable* state shouldn't be shared, AFAICT.
> Right, I missed this simple rule. My mind is still confined by my recent
> attempt to add security by only translating bytecode without any changes
> to the interpreter.

You were translating bytecode rather than working with ASTs? That would 
be hard to maintain, considering that Zope found it too difficult to 
maintain even manipulating concrete syntax trees. Also, I don't really 
consider that I'm modifying the interpreter, I'm just giving the 
interpreter a different globals dict.

>>I believing making
>>sure no mutable state is reachable through __builtins__
> Are you going to create multiple __builtins__ or you're just going
> to get rid of any global objects in __builtins__? The first lets you
> handle str.encode the right way.

I'm not sure what you mean by this. I'm creating a dict for 
__builtins__, but AFAIK it's not possible for code to modify the 
__builtins__ dict other than through the name __builtins__, which starts 
with an underscore and so is invalid. All of the objects I have in 
__builtins__ right now are immutable within the restricted environment 
because they're either functions or classes.

Python modules that are imported in the restricted environment will be 
read-only and each domain will get its own copy. This should prevent 
leaks caused by two domains importing the same module and then 
performing operations that affect the state of the module. Modules will 
need to explicitly specify what names they want to export the same way 
classes do in order to prevent inadvertent leaks.

>>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,
> Can C modules be imported more than once in CPython?

Not that I'm aware of, which is why they will need to be audited for 
mutable state and other sources of leaks and excess privilege. C modules 
that we need that have problems will get proxies the same way E has 
proxies for Swing.

More information about the Python-list mailing list