[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited) (original) (raw)

Wes Turner wes.turner at gmail.com
Mon Apr 11 21:52:10 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 Mon, Apr 11, 2016 at 8:08 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

Jon Ribbens wrote:

So far it looks like blocking "*" and the frame object attributes appears to be sufficient.

Even if your sandbox as it currently exists is secure, it's only an extremely restricted subset. You seem to be assuming that if your technique works so far, then it can be extended to cover a larger subset, but I don't think that's certain.

How would you test that?

One problem that's been raised is how to prevent untrusted code from monkeypatching imported modules. Possibly that could be addressed by giving the untrusted code a copy of the module, but I'm not entirely sure -- accidentally importing two copies of the same source file is a well-known source of bugs, after all.

https://en.wikipedia.org/wiki/Monkey_patch#Pitfalls

• https://pypi.python.org/pypi?%3Aaction=search&term=monkeypatch&submit=search

  • https://pypi.python.org/pypi/apparmor_monkeys

http://eventlet.net/doc/patching.html#monkeypatching-the-standard-library

• http://www.gevent.org/gevent.monkey.html
• https://docs.python.org/3/library/asyncio-sync.html#locks
• https://docs.python.org/2/library/threading.html#lock-objects
• https://docs.python.org/2/library/sets.html?highlight=immutable#sets.ImmutableSet
• http://doc.pypy.org/en/latest/stm.html#locks

• " Infinite recursion just segfaults for now."

• https://github.com/tobgu/pyrsistent #justfoundthis

  • https://github.com/tobgu/pyrsistent#invariants
  • https://github.com/tobgu/pyrsistent#freeze-and-thaw
    • freeze, thaw

• define a @property (and no @propname.setter)

  • https://docs.python.org/2/howto/descriptor.html#properties
  • https://docs.python.org/2/library/functions.html#property

A related, but more difficult problem is that if we allow the untrusted code to import any pure-Python classes, it will be able to monkeypatch them. So it seems like it will need its own copy of those classes as well --

• https://docs.python.org/3/library/importlib.html#importlib._import_

and having two copies of the same class around is another well known source of bugs.

One way to reduce the likelihood of this is to bundle all dependencies into a self-contained PEX ZIP package and specify entry points.

• http://legacy.python.org/dev/peps/pep-0441/
• https://pex.readthedocs.org/en/stable/buildingpex.html#specifying-entry-points
• https://pex.readthedocs.org/en/stable/buildingpex.html#tailoring-pex-execution-at-build-time

-- Greg

---

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160411/2e9a6913/attachment-0001.html>

• 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 ]

More information about the Python-Dev mailing list