Safe Python Execution

[Graham]

I've been messing around with trying to get a small sandbox like
environment where i could execute python code in a "safe" way.
Basically what the old restricted execution module attempted to do.
I've written a small amount of code to get custom interpreter running,
but i'm not really sure if its safe.

The way i'm controlling functionality is with some games and exec, so
if 'code' was the text code you wanted to execute i run:

exec code in {'__builtins__':None"}

obviously this doesn't give you much to play with, but it does remove
file access and importing as far as i can tell. Can anyone think of a
hack around this? I assume if it was this easy it would be a module
already but i figured i would ask.

Graham.

[Steven Bethard]

Graham wrote:

The way i'm controlling functionality is with some games and exec, so
if 'code' was the text code you wanted to execute i run:

exec code in {'__builtins__':None"}

obviously this doesn't give you much to play with, but it does remove
file access and importing as far as i can tell. Can anyone think of a
hack around this? I assume if it was this easy it would be a module
already but i figured i would ask.

Search the newsgroups, but one of the major problems is that all
subclasses of object are available through object.__subclasses__():

(1).__class__.__bases__[0].__subclasses__() [<type 'type'>, <type 'weakref'>, <type 'int'>, <type 'basestring'>,
....
<type 'dictproxy'>, <type 'code'>, <type 'frame'>]

Note that this also includes any classes you define that are subclasses
of object:
class C(object): .... dont_change_this = 42
.... exec '''\ .... subclasses = (1).__class__.__bases__[0].__subclasses__()
.... C, = [cls for cls in subclasses if cls.__name__ == 'C']
.... C.dont_change_this = 'bwahahaha'
.... ''' in {'__builtins__':None} C.dont_change_this

'bwahahaha'

So if you're really concerned about your objects being manipulated with
users, the ``exec code in {'__builtins__':None}`` technique is not going
to help you out. However, the code will be executed in restricted mode,
so things like the file constructor won't work. Not sure if that's
enough for you...

STeVe

[Devan L]

Graham wrote:

I've been messing around with trying to get a small sandbox like
environment where i could execute python code in a "safe" way.
Basically what the old restricted execution module attempted to do.
I've written a small amount of code to get custom interpreter running,
but i'm not really sure if its safe.

The way i'm controlling functionality is with some games and exec, so
if 'code' was the text code you wanted to execute i run:

exec code in {'__builtins__':None"}

obviously this doesn't give you much to play with, but it does remove
file access and importing as far as i can tell. Can anyone think of a
hack around this? I assume if it was this easy it would be a module
already but i figured i would ask.

You need to remove reload, replace __import__, disable __subclasses__
(not convenient nor portable because you need to do it in the source.
Shouldn't it be restricted in restricted mode?). That removes most
glaring security holes, I think. If you need to touch any of the
attributes of the objects in the sandbox, you might want to remove
properties. I wouldn't recommend exposing any objects outside of the
sandbox to the sandbox, either.

Zope also has some cool viral proxy thing that I don't understand that
you might want to look into.

[Paul Rubin]

"Graham" <gr***********@gmail.com> writes:

I've been messing around with trying to get a small sandbox like
environment where i could execute python code in a "safe" way.
Basically what the old restricted execution module attempted to do.

The old rexec module was removed for the precise reason that it wasn't
safe and there is no simple way to fix it.

[Alex Martelli]

Graham <gr***********@gmail.com> wrote:

I've been messing around with trying to get a small sandbox like
environment where i could execute python code in a "safe" way.
Basically what the old restricted execution module attempted to do.
I've written a small amount of code to get custom interpreter running,
but i'm not really sure if its safe.

The way i'm controlling functionality is with some games and exec, so
if 'code' was the text code you wanted to execute i run:

exec code in {'__builtins__':None"}

obviously this doesn't give you much to play with, but it does remove
file access and importing as far as i can tell. Can anyone think of a
hack around this? I assume if it was this easy it would be a module
already but i figured i would ask.

I suggest compiling the code and examining the names used in the code
object (co_names attribute of the code object which compile returns) --
refuse to execute the code if it mentions, defines or uses any special
name (starting and ending with two underscores). That, plus removing
almost all builtins as you do here, should be a good start.
Alex

[gene tani]

Jean-Paul Calderone wrote:

On Thu, 16 Feb 2006 07:59:03 -0800, Alex Martelli <al*****@yahoo.com> wrote:

Graham <gr***********@gmail.com> wrote:

I've been messing around with trying to get a small sandbox like
environment where i could execute python code in a "safe" way.
Basically what the old restricted execution module attempted to do.
I've written a small amount of code to get custom interpreter running,
but i'm not really sure if its safe.

The way i'm controlling functionality is with some games and exec, so
if 'code' was the text code you wanted to execute i run:

exec code in {'__builtins__':None"}

obviously this doesn't give you much to play with, but it does remove
file access and importing as far as i can tell. Can anyone think of a
hack around this? I assume if it was this easy it would be a module
already but i figured i would ask.

I suggest compiling the code and examining the names used in the code
object (co_names attribute of the code object which compile returns) --
refuse to execute the code if it mentions, defines or uses any special
name (starting and ending with two underscores). That, plus removing
almost all builtins as you do here, should be a good start.

A good start, perhaps, but still in need of a good finish.

"""
exec 'print ' + ''.join(map(chr, [
95, 95, 98, 117, 105, 108, 116, 105, 110, 115, 95, 95]))
"""

You can come up with a long list of restrictions to impose, and maybe that will be good enough. But making it /perfect/ is a Herculean task, as is maintaining it as new Python releases are made, and auditing it every time you add a new piece of code to your system.

What about what's in zope, :
http://svn.zope.org/Zope3/trunk/src/....txt?view=auto

[dbpokorny]

It looks like untrustedinterpreter has at least two major obstacles to
executing reasonably complex code:

augmented assignment is not supported:
a.b = 'foo'
is translated into
__getattr__(a,b) = 'foo'

Second, this is mysterious, but nevertheless...
"""This form of restricted Python assumes that security proxies will be
used to protect assets. Given this, the only thing that actually
needs to be done differently by the generated code is to:
<some other items>
- Prevent try/except and raise statements. This is mainly because they
don't work properly in the presense of security proxies. Try/except
statements will be made to work in the future.
"""
--Zope-3.2.0/Dependencies/zope.security-Zope-3.2.0/zope.security/untrustedpython/rcompile.txt

Is anyone aware of a more functional but still untrusted python? One
could remove the ability to access pipes & files from regular python,
build it, and launch the resulting python-slave from a (normal python)
master process... However I'm pretty confident that if I did this
myself, I'd leave more than a few glaring security holes for an
ambitious 9-year-old.

Any help appreciated!

David

[Paul Boddie]

db*******@gmail.com wrote:

Is anyone aware of a more functional but still untrusted python?

Given that you've looked into Zope 3's security/proxy mechanisms, have
you also looked at mxProxy?

http://www.egenix.com/files/python/mxProxy.html

Paul