limited python virtual machine (WAS: Another scripting language implemented into Python itself?)

Cameron Laird claird at lairds.us
Wed Jan 26 00:08:13 CET 2005


In article <mailman.1301.1106686318.22381.python-list at python.org>,
Michael Spencer  <mahs at telcopartners.com> wrote:
			.
			.
			.
>Right - the crux of the problem is how to identify dangerous objects.  My point 
>is that if such as test is possible, then safe exec is very easily implemented 
>within current Python. If it is not, then it is essentially impossible.
>
>Let's assume that it is indeed not possible to know in general whether
>an object 
>is safe, either by inspecting its attributes, or by matching its identity 
>against a black list.
>
>It might still be possible to have a reliable test within a problem-specific 
>domain i.e., white-listing.  This, I think, is what you meant when you said:
>
>> I wish there was a way to, say, exec something with no builtins and
>with import disabled, so you would have to specify all the available
>bindings, e.g.:
>> 
>>     exec user_code in dict(ClassA=ClassA, ClassB=ClassB) 
>
>I believe that if you can come up with a white-list, then the rest of the 
>problem is easy.
>
>Michael
>

I'll suggest yet another perspective:  add another indirection.
As the virtual machine becomes more available to introspection,
it might become natural to define a *very* restricted interpreter
which we can all agree is safe, PLUS a means to extend that 
specific instance of the VM with, say, new definitions of bindings
for particular AST nodes.  Then the developer has the means to
"build out" his own VM in a way he can judge useful and safe for
his own situation.  Rather than the Java there-is-one-"safe"-for-
all approach, Pythoneers would have the tools to create safety.



More information about the Python-list mailing list