On Wed, Feb 29, 2012 at 3:52 PM, Victor Stinner <victor.stin...@haypocalc.com> wrote: >> It would (apparently) help Victor to fix issues in his pysandbox >> project. I don't know if a secure Python sandbox is an important >> enough concept to warrant core changes to make it possible. > > Ok, let's talk about sandboxing and security. > > The main idea of pysandbox is to reuse most of CPython but hide > "dangerous" functions and run untrusted code in a separated namespace. > The problem is to create the sandbox and ensure that it is not > possible to escape from this sandbox. pysandbox is still a > proof-of-concept, even if it works pretty well for short dummy > scripts. But pysandbox is not ready for real world programs.
I hope you have studied (recent) history. Sandboxes in Python traditionally have not been secure. Read the archives for details. > pysandbox uses various "tricks" and "hacks" to create a sandbox. But > there is a major issue: the __builtins__ dict (or module) is available > and used everywhere (in module globals, in frames, in functions > globals, etc.), and can be modified. A read-only __builtins__ dict is > required to protect the sandbox. If the untrusted can modify > __builtins__, it can replace core functions like isinstance(), len(), > ... and so modify code outside the sandbox. > > To implement a frozendict in Python, pysandbox uses the blacklist > approach: a class inheriting from dict and override some methods to > raise an error. The whitelist approach cannot be used for a type > implemented in Python, because the __builtins__ type must inherit from > dict: ceval.c expects a type compatible with PyDict_GetItem and > PyDict_SetItem. > > Problem: if you implement a frozendict type inheriting from dict in > Python, it is still possible to call dict methods (e.g. > dict.__setitem__()). To fix this issue, pysandbox removes all dict > methods modifying the dict: __setitem__, __delitem__, pop, etc. This > is a problem because untrusted code cannot use these methods on valid > dict created in the sandbox. > >> However, >> if Victor was saying that implementing this PEP was all that is needed >> to implement a secure sandbox, then that would be a very different >> claim, and likely much more compelling (to some, at least - I have no >> personal need for a secure sandbox). > > A builtin frozendict type "compatible" with the PyDict C API is very > convinient for pysandbox because using this type for core features > like builtins requires very few modification. For example, use > frozendict for __builtins__ only requires to modify 3 lines in > frameobject.c. > > I don't see how to solve the pysandbox issue (read-only __builtins__ > issue, need to remove dict.__setitem__ & friends) without modifying > CPython (so without adding a frozendict type). > >> As it stands, I don't find the PEP compelling. The hardening use case >> might be significant but Victor needs to spell it out if it's to make >> a difference. > > I don't know if hardening Python is a compelling argument to add a new > builtin type. > > Victor > _______________________________________________ > 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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
