Creating a reliable sandboxed Python environment

[Chris Angelico]

On Sun, May 31, 2015 at 6:00 AM, Paul Rubin <no.email at nospam.invalid> wrote:
> Steven D'Aprano <steve at pearwood.info> writes:
>> I wouldn't have imagined that the claim "it's easier to secure a small
>> language with a few features than a big language with lots of features"
>> would have been so controversial.
>
> Consider that if the small language is Turing-complete, you can use it
> to implement the big language.  If the small language is also secure (in
> the sense of not being able to escape a sandbox), the big language
> implemented in it can't escape the sandbox either.  Therefore the size
> of the language doesn't inherently affect the sandbox security.

Turing completeness isn't the whole story. How do you go about
sandboxing a Brainf* implementation such that it can be used to
implement Python, but can't be used to read or arbitrary files from
your file system? Will you reimplement the Python standard library in
Brainf*? Will you implement open(), but nerf it? Will you make sure
there's nothing anywhere in the stdlib that can open files? And if you
_don't_ provide a reimplemented standard library, you either need to
provide an import mechanism (so you can make use of the existing
Python code) or declare that the language as a whole is neutered by a
complete lack of all those features that are implemented in Python.

ChrisA