[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited) (original) (raw)
Chris Angelico rosuav at gmail.com
Tue Apr 12 08:05:22 EDT 2016
- Previous message (by thread): [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)
- Next message (by thread): [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Apr 12, 2016 at 9:10 PM, Jon Ribbens <jon+python-dev at unequivocal.co.uk> wrote:
On Tue, Apr 12, 2016 at 08:27:14PM +1000, Chris Angelico wrote:
decimal.getcontext is a simple and obvious example of a way that global mutable objects can be accessed across the boundary. There is no way to mathematically prove that there are no more, so it's still a matter of blacklisting. No, it's a matter of reducing the whitelist. I must admit that I don't understand in what way this is not already clear. Look: >>> len(unsafe.SAFEMODULES) 23 I could "mathematically prove" that there are no more security holes in that list by reducing its length to zero. There are still plenty of circumstances in which the experiment would be a useful tool even with no modules allowed to be imported.
Yes, you just removed decimal because of getcontext. What about the next module with that kind of issue? Or what about the next non-underscore attribute on a core type that can cause you grief (like how async functions leak stack frames)?
I still think you need to work out a "minimum viable set" and set down some concrete rules: if any feature in this set has to be blacklisted in order to achieve security, the experiment has failed. The "minimum viable set" in my view would be: no builtins at all, only allowing eval() not exec(), and disallowing yield [from], lambdas and generator expressions.
Then start with that. Don't give ANYTHING else. Otherwise you're still playing with the blacklist.
But at that point, you pretty much have something that can't be recognized as Python. You may as well start from a completely different basis and design your own expression evaluator, maybe making use of parse-to-AST, but not actually eval'ing the source code. That's how fundamental this issue is - to dodge the security problems, you get to the point where you've dodged all of what makes Python Python.
ChrisA
- Previous message (by thread): [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)
- Next message (by thread): [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]