On Mon, 11 Apr 2016, Victor Stinner wrote:
2016-04-10 18:43 GMT+02:00 Jon Ribbens <jon+python-...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
