mirror of https://github.com/python/cpython
69 lines
3.2 KiB
ReStructuredText
69 lines
3.2 KiB
ReStructuredText
|
|
.. _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.
|
|
|