limited python virtual machine

[Nick Coghlan]

Alex Martelli wrote:
> Steven Bethard <steven.bethard at gmail.com> wrote:
>    ...
> 
>>If I could see how to go from 'object' (or 'int', 'str', 'file', etc.)
>>to 'eval' or '__import__', that would help out a lot...
> 
> 
>>>>object.__subclasses__()
> 
> [<type 'type'>, <type 'weakref'>, <type 'int'>, <type 'basestring'>,
> <type 'list'>, <type 'NoneType'>, <type 'NotImplementedType'>, <type
> 'module'>, <type 'zipimport.zipimporter'>, <type 'posix.stat_result'>,
> <type 'posix.statvfs_result'>, <type 'dict'>, <type 'function'>, <class
> 'site._Printer'>, <class 'site._Helper'>, <type 'set'>, <type 'file'>]
> 
> Traipse through these, find one class that has an unbound method, get
> that unbound method's func_globals, bingo.

So long as any Python modules are imported using the same restricted environment 
  their func_globals won't contain eval() or __import__ either.

And C methods don't have func_globals at all.

However, we're talking about building a custom interpreter here, so there's no 
reason not to simply find the dangerous functions at the C-level and replace 
their bodies with "PyErr_SetString(PyExc_Exception, "Access to this operation 
not allowed in restricted build"); return NULL;".

Then it doesn't matter *how* you get hold of file(), it still won't work. (I can 
hear the capabilities folks screaming already. . .)

Combine that with a pre-populated read-only sys.modules and a restricted custom 
interpreter would be quite doable. Execute it in a separate process and things 
should be fairly solid.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net