Creating a capabilities-based restricted execution system
Sean R. Lynch
seanl at chaosring.org
Sun Jan 4 23:54:30 EST 2004
More information about the Python-list mailing list
Sun Jan 4 23:54:30 EST 2004
- Previous message (by thread): Creating a capabilities-based restricted execution system
- Next message (by thread): Creating a capabilities-based restricted execution system
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message (by thread): Creating a capabilities-based restricted execution system
- Next message (by thread): Creating a capabilities-based restricted execution system
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list