Simple Python Sandbox

[geremy condra]

On Sat, Aug 14, 2010 at 12:56 PM, Stephen Hansen
<me+list/python at ixokai.io> wrote:
> 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.

I assume you're cutting out the import machinery?

Geremy Condra