Simple Python Sandbox

[Stephen Hansen]

On 8/13/10 8:04 PM, Steven D'Aprano wrote:
> On Fri, 13 Aug 2010 16:37:40 -0700, Stephen Hansen wrote:
> 
>> Howdy-ho.
>>
>> So, I'm working on a project which embeds Python into a bigger system to
>> provide extensibility. In this project, there's basically two types of
>> people who will be entering python code.
>>
>> The trusted folks, who write code which are in files, and which can do
>> anything.
>>
>> The untrusted folks, who are writing very simple chunks of code which
>> can only do limited things.
> 
> I suggest that if the untrusted code is only supposed to be simple and 
> limited, you would be best off to write your own "mini-language" using 
> Python syntax. 

I considered it and rejected it. The return from the effort required
doesn't even vaguely come close to making it worth it. My worst case
fall-back plan is to embed /another/ language (be it Lua or JavaScript
through V8) and offer it a very limited environment. But I don't want to
do that (and considering I solved the while True: pass problem last
night, I'm pretty sure I won't decide to).

> The fact is that Python is not designed to be used by untrusted users, 
> and it is REALLY hard to keep it in a sandbox. There was an attempt to 
> sandbox Python, if I recall correctly it was the bastion module, but it 
> turned out to be so leaky that it was removed from the standard library 
> with extreme prejudice. Since then, others have been working on it, 
> including Google, but I don't know how successful they've been.

I know all this -- but its not relevant really, I think. I'm not trying
to create a safe yet relatively complete or functional Python. All those
efforts to sandbox Python fail because of the incredible dynamic nature
of the language has lots of enticing little holes in it. But I'm not
interested in a full or even vaguely full subset of Python, and I'm not
requiring that this security be done on the code-level.

For example, when you go to save your bit of code, it will go in and if
it finds __ anywhere in the text it just replaces it with xx. And, since
getattr is not available, '_' + '_' won't get you anywhere.

> Here's an example... suppose you wish to allow reading files, but not 
> writing them. Sounds simple?
> 
> http://tav.espians.com/a-challenge-to-break-python-security.html

Yeah, I'm aware of this little challenge-- but every one of those
exploits calls for a special attribute call or method creation which is
impossible(I think) in my setup.

Although Paul Cannon's little exploit is very interesting, and I'm going
to go brute force murder try/except in a similar way to __ above (in
this context, exceptions aren't important) now.

> Now, I'm not suggesting that the exploits there are directly applicable 
> to your sandbox, but they give a small idea of the sorts of things you 
> need to consider.

I'm creating a much, much more restrictive subset of Python then most
sandboxes try to do-- I could make my own custom mini-language, except
good lord, that's a whole lot of work since there are real needs for
*some* programming power here. Or I could embed another language in a
more restrictive way then Python is embedded-- but good lord, now I have
to handle three languages to get things done :)

I just need a certain limited context where someone can be handed
certain Python objects and manipulate them. I'd like people to be able
to use some fundamental Python power -- the rich, beautiful data types
for example (notably in this case, strings), list comprehensions and
stuff, to do what they need to do. Python's very easy, I'd like them to
be able to use that easy.

But I don't need anywhere near full Python power, so sweeping rules
like, 'no, you can't even type __' or, 'sorry, no exception handling for
you', work well.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20100814/7396efd2/attachment.sig>