Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Safe Python Execution

5 views
Skip to first unread message

Graham

unread,
Feb 15, 2006, 10:00:30 PM2/15/06
to
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

unread,
Feb 15, 2006, 11:14:56 PM2/15/06
to
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

unread,
Feb 15, 2006, 11:43:52 PM2/15/06
to

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

unread,
Feb 16, 2006, 12:48:32 AM2/16/06
to
"Graham" <graham...@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

unread,
Feb 16, 2006, 10:59:03 AM2/16/06
to
Graham <graham...@gmail.com> wrote:

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

Jean-Paul Calderone

unread,
Feb 16, 2006, 12:44:25 PM2/16/06
to pytho...@python.org

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.

Just keep that in mind if you decide to pursue this.

Jean-Paul

gene tani

unread,
Feb 16, 2006, 1:57:50 PM2/16/06
to

dbpo...@gmail.com

unread,
Feb 21, 2006, 2:05:38 AM2/21/06
to
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

unread,
Feb 21, 2006, 3:36:33 AM2/21/06
to
dbpo...@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

0 new messages