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/
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list
