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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4