[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

[Isaac Morland]

On Mon, 11 Apr 2016, Victor Stinner wrote:

> 2016-04-10 18:43 GMT+02:00 Jon Ribbens <jon+python-dev at unequivocal.co.uk>:
>>
>> That's the opposite of my approach though - I'm starting small and
>> adding things, not starting with everything and removing stuff. Even
>> if what we end up with is an extremely restricted subset of Python,
>> there are still cases where that could be a useful tool to have.
>
> You design rely on the assumption that CPython is only pure Python.
> That's wrong. A *lot* of Python features are implemented in C and
> "ignore" your sandboxing code. Quick reminder: 50% of CPython is
> written in the C language.
>
> It means that your protections like hiding builtin functions from the
> Python scope don't work. If an attacker gets access to a C function
> giving access to the hidden builtin, the game is over.
[....]

Non-Python core developer, non-expert-specifically-in-computer-security 
here, so won't take up much room on this list.

I know enough about almost everything in Computer Science to know just how 
ignorant I am about almost everything in Computer Science.

But I would not use for security purposes a Python sandbox that was not 
formally verified to be correct and unbreakable.  Of course in order for 
this to be possible, there first has to be a formal semantics for Python. 
Has anybody made a formal semantics for Python?  If not, then this project 
is missing a pretty important pre-requisite.

Isaac Morland           CSCF Web Guru
DC 2619, x36650         WWW Software Specialist