Creating a capabilities-based restricted execution system

[John Roth]

"Sean R. Lynch" <seanl at chaosring.org> wrote in message
news:9Jecnc6TZdy4lGqiXTWc-w at speakeasy.net...
> John Roth wrote:
>
> > Yes,  you're missing something really obvious. Multi-level
> > security is a real difficult problem if you want to solve it
> > in a believable (that is, bullet-proof) fashion. The only way
> > I know of solving it is to provide separate execution
> > environments for the different privilege domains.
> > In the current Python structure, that means different
> > interpreters so that the object structures don't intermix.
>
> Hmmm, can you give me an example of a Python application that works this
> way? Zope seems to be doing fine using RestrictedPython.
> RestrictedPython is, in fact, an attempt to provide different execution
> environments within the same memory space, which is the whole point of
> my exercise. Now, I know that the lack of an example of insecurity is
> not proof of security, but can you think of a way to escape from
> RestrictedPython's environment? DoS is still possible, but as I'm not
> planning on using this for completely untrusted users, I'm not too
> concerned about that.

Restricted Python was withdrawn because of a number of
holes, of which new style classes were the last straw. I don't
know what the exact holes were.

Whether Zope security is subject to those holes is a question
I can't answer (and I don't find it all that interesting, anyway.)
The Restricted Execution environment's disabling access to
__dict__ seems a bit ham-handed, but I suspect that it was
simply the easiest way around one major difficulty. The Bastion
hook (which is what I believe Zope security is built on top of)
seems to be reasonably adequate. The rest of it probably
needs to be rethought.

John Roth