Doc/lib/librestricted.tex

   1 \chapter{Restricted Execution \label{restricted}}
   2
   3 \begin{notice}[warning]
   4    In Python 2.3 these modules have been disabled due to various known
   5    and not readily fixable security holes.  The modules are still
   6    documented here to help in reading old code that uses the
   7    \module{rexec} and \module{Bastion} modules.
   8 \end{notice}
   9
  10 \emph{Restricted execution} is the basic framework in Python that allows
  11 for the segregation of trusted and untrusted code.  The framework is based on the
  12 notion that trusted Python code (a \emph{supervisor}) can create a
  13 ``padded cell' (or environment) with limited permissions, and run the
  14 untrusted code within this cell.  The untrusted code cannot break out
  15 of its cell, and can only interact with sensitive system resources
  16 through interfaces defined and managed by the trusted code.  The term
  17 ``restricted execution'' is favored over ``safe-Python''
  18 since true safety is hard to define, and is determined by the way the
  19 restricted environment is created.  Note that the restricted
  20 environments can be nested, with inner cells creating subcells of
  21 lesser, but never greater, privilege.
  22
  23 An interesting aspect of Python's restricted execution model is that
  24 the interfaces presented to untrusted code usually have the same names
  25 as those presented to trusted code.  Therefore no special interfaces
  26 need to be learned to write code designed to run in a restricted
  27 environment.  And because the exact nature of the padded cell is
  28 determined by the supervisor, different restrictions can be imposed,
  29 depending on the application.  For example, it might be deemed
  30 ``safe'' for untrusted code to read any file within a specified
  31 directory, but never to write a file.  In this case, the supervisor
  32 may redefine the built-in \function{open()} function so that it raises
  33 an exception whenever the \var{mode} parameter is \code{'w'}.  It
  34 might also perform a \cfunction{chroot()}-like operation on the
  35 \var{filename} parameter, such that root is always relative to some
  36 safe ``sandbox'' area of the filesystem.  In this case, the untrusted
  37 code would still see an built-in \function{open()} function in its
  38 environment, with the same calling interface.  The semantics would be
  39 identical too, with \exception{IOError}s being raised when the
  40 supervisor determined that an unallowable parameter is being used.
  41
  42 The Python run-time determines whether a particular code block is
  43 executing in restricted execution mode based on the identity of the
  44 \code{__builtins__} object in its global variables: if this is (the
  45 dictionary of) the standard \refmodule[builtin]{__builtin__} module,
  46 the code is deemed to be unrestricted, else it is deemed to be
  47 restricted.
  48
  49 Python code executing in restricted mode faces a number of limitations
  50 that are designed to prevent it from escaping from the padded cell.
  51 For instance, the function object attribute \member{func_globals} and
  52 the class and instance object attribute \member{__dict__} are
  53 unavailable.
  54
  55 Two modules provide the framework for setting up restricted execution
  56 environments:
  57
  58 \localmoduletable
  59
  60 \begin{seealso}
  61   \seetitle[http://grail.sourceforge.net/]{Grail Home Page}
  62            {Grail, an Internet browser written in Python, uses these
  63             modules to support Python applets.  More
  64             information on the use of Python's restricted execution
  65             mode in Grail is available on the Web site.}
  66 \end{seealso}