Creating a reliable sandboxed Python environment

Paul Rubin no.email at nospam.invalid
Sat May 30 00:48:23 EDT 2015


Chris Angelico <rosuav at gmail.com> writes:
> You can *easily* sandbox something that has very little functionality
> - all you have to do is provide a minimalist "language" that permits
> only a very few actions, and you know it's safe. But that security
> comes at a price.

This is a non-sequitur.  The reason they didn't put more features into
Lua is that it would have made the memory footprint bigger and they
pitch it as an embeddable extension engine so they want to keep it
small.  Stuff like bignums and unicode in themselves wouldn't have
affected security.  There's no obstacle to implementing Python the way
Lua is implemented, and for all I know, MicroPython does that.  It just
didn't happen to be done that way with CPython because of Python's
expected mode of use historically.  Armin Ronacher's blog entry that I
linked says a little more about this.

Heck, think of Java, which is monstrously more complicated than Python
and supports applet sandboxing, plus it can run Python programs (under
Jython).  Or Javascript, which has similar complexity to Python and runs
sandboxes in millions (billions?) of browsers.



More information about the Python-list mailing list