Creating a capabilities-based restricted execution system
Sean R. Lynch
seanl at chaosring.org
Sun Jan 4 23:54:30 EST 2004
Serge Orlov wrote:
> "Sean R. Lynch" <seanl at chaosring.org> wrote in message news:mvScnSDrma66AWWiXTWc-g at speakeasy.net...
>>
>>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