Creating a capabilities-based restricted execution system

[Serge Orlov]

"Sean R. Lynch" <seanl at chaosring.org> wrote in message news:mvScnSDrma66AWWiXTWc-g at speakeasy.net...
> Serge Orlov wrote:
> > "Sean R. Lynch" <seanl at chaosring.org> wrote in message news:srudnTjvU9BOH2qiRVn-uA at speakeasy.net...
> >
> > 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.

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.

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

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

> which
> should be possible with a modified __import__ builtin. I don't have any
> intention of allowing import of unaudited C modules.

Agreed.

-- Serge.