On Sat, Aug 14, 2010 at 12:56 PM, Stephen Hansen <me+list/pyt...@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 -- http://mail.python.org/mailman/listinfo/python-list
