Simple Python Sandbox
steve at REMOVE-THIS-cybersource.com.au
Sat Aug 14 05:04:17 CEST 2010
On Fri, 13 Aug 2010 16:37:40 -0700, Stephen Hansen wrote:
> 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
> 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?
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.
More information about the Python-list