Simple Python Sandbox

[Steven D'Aprano]

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. E.g. if the untrusted users are only going to write code 
that does (say) simple arithmetic, then why give them the ability to 
create closures, use generator expressions, connect to web servers, etc?

You might think that it's a lot of work to write a mini-language, even 
with the tools in the standard library, and it is. But it will probably 
be less work than securing Python :)

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.

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


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.


-- 
Steven