| |
| .. _restricted: |
| |
| ******************** |
| Restricted Execution |
| ******************** |
| |
| .. warning:: |
| |
| In Python 2.3 these modules have been disabled due to various known and not |
| readily fixable security holes. The modules are still documented here to help |
| in reading old code that uses the :mod:`rexec` and :mod:`Bastion` modules. |
| |
| *Restricted execution* is the basic framework in Python that allows for the |
| segregation of trusted and untrusted code. The framework is based on the notion |
| that trusted Python code (a *supervisor*) can create a "padded cell' (or |
| environment) with limited permissions, and run the untrusted code within this |
| cell. The untrusted code cannot break out of its cell, and can only interact |
| with sensitive system resources through interfaces defined and managed by the |
| trusted code. The term "restricted execution" is favored over "safe-Python" |
| since true safety is hard to define, and is determined by the way the restricted |
| environment is created. Note that the restricted environments can be nested, |
| with inner cells creating subcells of lesser, but never greater, privilege. |
| |
| An interesting aspect of Python's restricted execution model is that the |
| interfaces presented to untrusted code usually have the same names as those |
| presented to trusted code. Therefore no special interfaces need to be learned |
| to write code designed to run in a restricted environment. And because the |
| exact nature of the padded cell is determined by the supervisor, different |
| restrictions can be imposed, depending on the application. For example, it |
| might be deemed "safe" for untrusted code to read any file within a specified |
| directory, but never to write a file. In this case, the supervisor may redefine |
| the built-in :func:`open` function so that it raises an exception whenever the |
| *mode* parameter is ``'w'``. It might also perform a :c:func:`chroot`\ -like |
| operation on the *filename* parameter, such that root is always relative to some |
| safe "sandbox" area of the filesystem. In this case, the untrusted code would |
| still see an built-in :func:`open` function in its environment, with the same |
| calling interface. The semantics would be identical too, with :exc:`IOError`\ s |
| being raised when the supervisor determined that an unallowable parameter is |
| being used. |
| |
| The Python run-time determines whether a particular code block is executing in |
| restricted execution mode based on the identity of the ``__builtins__`` object |
| in its global variables: if this is (the dictionary of) the standard |
| :mod:`__builtin__` module, the code is deemed to be unrestricted, else it is |
| deemed to be restricted. |
| |
| Python code executing in restricted mode faces a number of limitations that are |
| designed to prevent it from escaping from the padded cell. For instance, the |
| function object attribute :attr:`func_globals` and the class and instance object |
| attribute :attr:`__dict__` are unavailable. |
| |
| Two modules provide the framework for setting up restricted execution |
| environments: |
| |
| |
| .. toctree:: |
| |
| rexec.rst |
| bastion.rst |
| |
| .. seealso:: |
| |
| `Grail Home Page <http://grail.sourceforge.net/>`_ |
| Grail, an Internet browser written in Python, uses these modules to support |
| Python applets. More information on the use of Python's restricted execution |
| mode in Grail is available on the Web site. |
| |