Secure Python

[Stephan Kuhagen]

timmy <"timothy at open-networks.net"> wrote:

>> count and limit the number of evaluation steps allowed for untrusted
>> script or methods in untrusted script as well as to limit the recursion
>> depth or memory to be allocated.
> 
> idunno sounds like a lot of trouble to engineer a solution that has
> already got a solution. all win NT systems have resource managment and i
> imagine OS X would as well??

Sounds very likely, but does not solve the problem. With resource management
on the OS level you can indeed set some important limits for untrusted
scripts, but there are at least two drawbacks, which come to my mind (and
maybe more, that I'm not aware of): 1. OS level can always only implement
the lowest common denominator of all OS resource managements to be platform
independent, which is a strong requirement, IMO. 2. If you want to exec a
untrusted script from inside a trusted interpreter giving it a sandbox,
then the sandbox has the same OS level restrictions as the first
interpreter (except when started in a separate process, which makes
communication between trusted and untrusted parts much more complicated).
Also you can't have such a fine grained control over the untrusted
execution environment at the OS level, e.g. limiting the recursion depth,
which is a very important limit for secure interpreters. Limiting the stack
on the OS level is for example no solution for this, because the byte code
may behave completely different on the stack (and regarding hidden internal
recursion) as what the toplevel Python code does (does anyone understand,
what I'm talking about... - I think I just reached the recurion limit of my
english capabilities), which means that you can't set deterministic
restrictions for untrusted code in a platform independent manner at the OS
level. - Managing all this in the interpreter would solve the problem, at
the cost of implementing lots of resource management code. A good sandbox
seems to be a real adventure with few survivors, as can be seen in the
JavaScript-world.

Regards
Stephan