62 lines
2.9 KiB
TeX
62 lines
2.9 KiB
TeX
|
\chapter{Restricted Execution}
|
||
|
|
|
||
|
|
In general, executing Python programs have complete access to the
|
||
|
|
underlying operating system through the various functions and classes
|
||
|
|
contained in Python's modules. For example, a Python program can open
|
||
|
|
any file\footnote{Provided the underlying OS gives you permission!}
|
||
|
|
for reading and writing by using the
|
||
|
|
\code{open()} built-in function. This is exactly what you want for
|
||
|
|
most applications.
|
||
|
|
|
||
|
|
There is a class of applications for which this ``openness'' is
|
||
|
|
inappropriate. Imagine a web browser that accepts ``applets'', snippets of
|
||
|
|
Python code, from anywhere on the Internet for execution on the local
|
||
|
|
system. Since the originator of the code is unknown, it is obvious that it
|
||
|
|
cannot be trusted with the full resources of the local machine.
|
||
|
|
|
||
|
|
\emph{Restricted execution} is the basic Python framework that allows
|
||
|
|
for the segregation of trusted and untrusted code. It is based on the
|
||
|
|
notion that trusted Python code (a \emph{supervisor}) can create a
|
||
|
|
``padded cell' (or environment) of 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 the term ``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, privledge.
|
||
|
|
|
||
|
|
An interesting aspect of Python's restricted execution model is that
|
||
|
|
the attributes 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
|
||
|
|
\code{open()} function so that it raises an exception whenever the
|
||
|
|
\var{mode} parameter is \code{'w'}. It might also perform a
|
||
|
|
\code{chroot()}-like operation on the \var{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
|
||
|
|
\code{open()} function in its \code{__builtin__} module, with the same
|
||
|
|
calling interface. The semantics would be identical too, with
|
||
|
|
\code{IOError}s being raised when the supervisor determined that an
|
||
|
|
unallowable parameter is being used.
|
||
|
|
|
||
|
|
Two modules provide the framework for setting up restricted execution
|
||
|
|
environments:
|
||
|
|
|
||
|
|
\begin{description}
|
||
|
|
|
||
|
|
\item[rexec]
|
||
|
|
--- Basic restricted execution framework.
|
||
|
|
|
||
|
|
\item[Bastion]
|
||
|
|
--- Providing restricted access to objects.
|
||
|
|
|
||
|
|
\end{description}
|