[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)
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