All, Thanks for the quick responses!
I've skimmed the pysandbox code yesterday. I think Victor has the right idea with relying on a whitelist, as well as limiting execution time. The fact that untrusted code can still execute memory exhaustion attacks is the only thing that still worries me: It's hard to write a server that will run hundreds of scripts from untrusted users, since one of them can bring down the entire server by writing an infinite loop that allocates tons of objects. Python needs a way to hook the object-allocation process in order to (effectively) limit how much memory untrusted code can consume. Tav's blog post makes some interesting points... The object-capability model definitely has the benefit of efficiency; simply getting the reference to an object means the untrusted code is trusted with full capability to that object (which saves having to query the jail every time the object is touched) - it's just as fast as unrestricted Python, which I like. Perhaps my jails idea should then be refactored into some mechanism for monitoring and limiting memory and CPU usage -- it's the perfect thing to ship as an extension, the only shame is that it requires interpreter support. Anyway, in light of Tav's post which seems to suggest that f_restricted frames are impossible to escape (if used correctly), why was f_restricted removed in Python 3? Is it simply that it's too easy to make a mistake and accidentally give an attacker an unsafe object, or is there some fundamental flaw with it? Could you see something like f_restricted (or f_jail) getting put back in Python 3, if it were a good deal more bulletproof? And, yeah, I've been playing with RestrictedPython. It's pretty good, but it lacks memory- and CPU-limiting, which is my main focus right now. And yes, I should probably have posted this to python-ideas, thanks. :) This is a very long way away from a PEP. PyPy's sandboxing feature is probably closest to what I'd like, but I'm looking for something that can coexist in the same process (since running hundreds of interpreter processes continuously has a lot of system memory overhead, it's better if the many untrusted, but independent, jails could share a single interpreter) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
