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 -- http://mail.python.org/mailman/listinfo/python-list
