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

Isaac Morland ijmorlan at uwaterloo.ca
Mon Apr 11 07:04:56 EDT 2016

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

More information about the Python-Dev mailing list