On Sun, Apr 10, 2016 at 10:19:06PM +0000, David Wilson wrote: > On Sun, Apr 10, 2016 at 06:17:29PM +0100, Jon Ribbens wrote: > > Further to the success of dojo participants in breaking out of my > > sandbox experiment due to a stupid bug I'd created, I've both > > tightened up the sandbox and extended it by adding back in 'with' > > and 'import' (of white-listed modules). > > > > If anyone would like to have another go at breaking out of it, > > I'd be interested to hear their results: > > I guess it goes without saying, but just in case, the core team gave up > on any possibility of in-process sandboxing a very long time ago, and > all popular implementations are designed with pretty much zero regard > for this use case.
I know, I've been discussing this on comp.lang.python and python-dev as well. It's mostly an experiment to see where we can get with static code analysis using the 'ast' module, which as far as I can tell nobody else has tried before. > If you want a real sandbox use an OS supplied facility that's been > reviewed to exhaustion like seccomp on Linux, although sadly there are > no good wrappers to use Python within seccomp. > > There is some example code for seccomp here: > http://pythonsweetness.tumblr.com/post/65442885019/secure-low-overhead-eval-sandbox-in-80-lines-of > but really this wants wrapped up in a neat library to be generally > useful. Jon are you up for that? :) That link has already got some fairly neat code in it, although as they mention it leaks the parent process's memory to the child, which makes it useless in my opinion. It really needs to be using exec(), but that's obviously hard to do in a generic library. _______________________________________________ python-uk mailing list python-uk@python.org https://mail.python.org/mailman/listinfo/python-uk
