Creating a capabilities-based restricted execution system

[Aahz]

In article <vveg0bb6is2f60 at news.supernews.com>,
John Roth <newsgroups at jhrothjr.com> wrote:
>"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.

RestrictedPython was *not* withdrawn; rexec was withdrawn.  This is a
difficult enough issue to discuss without confusing different modules.  See 
http://dev.zope.org/Wikis/DevSite/Projects/SupportPython21/RestrictedPython
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.