Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit c3d090c

Browse files
gvanrossumgvanrossum
committed
Background chapter on restricted execution. Additional sections are
rexec and bastion.
1 parent 9cb018e commit c3d090c

2 files changed

Lines changed: 122 additions & 0 deletions

File tree

‎Doc/lib/librestricted.tex‎

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
\chapter{Restricted Execution}
2+
3+
In general, executing Python programs have complete access to the
4+
underlying operating system through the various functions and classes
5+
contained in Python's modules. For example, a Python program can open
6+
any file\footnote{Provided the underlying OS gives you permission!}
7+
for reading and writing by using the
8+
\code{open()} built-in function. This is exactly what you want for
9+
most applications.
10+
11+
There is a class of applications for which this ``openness'' is
12+
inappropriate. Imagine a web browser that accepts ``applets'', snippets of
13+
Python code, from anywhere on the Internet for execution on the local
14+
system. Since the originator of the code is unknown, it is obvious that it
15+
cannot be trusted with the full resources of the local machine.
16+
17+
\emph{Restricted execution} is the basic Python framework that allows
18+
for the segregation of trusted and untrusted code. It is based on the
19+
notion that trusted Python code (a \emph{supervisor}) can create a
20+
``padded cell' (or environment) of limited permissions, and run the
21+
untrusted code within this cell. The untrusted code cannot break out
22+
of its cell, and can only interact with sensitive system resources
23+
through interfaces defined, and managed by the trusted code. The term
24+
``restricted execution'' is favored over the term ``safe-Python''
25+
since true safety is hard to define, and is determined by the way the
26+
restricted environment is created. Note that the restricted
27+
environments can be nested, with inner cells creating subcells of
28+
lesser, but never greater, privledge.
29+
30+
An interesting aspect of Python's restricted execution model is that
31+
the attributes presented to untrusted code usually have the same names
32+
as those presented to trusted code. Therefore no special interfaces
33+
need to be learned to write code designed to run in a restricted
34+
environment. And because the exact nature of the padded cell is
35+
determined by the supervisor, different restrictions can be imposed,
36+
depending on the application. For example, it might be deemed
37+
``safe'' for untrusted code to read any file within a specified
38+
directory, but never to write a file. In this case, the supervisor
39+
may redefine the built-in
40+
\code{open()} function so that it raises an exception whenever the
41+
\var{mode} parameter is \code{'w'}. It might also perform a
42+
\code{chroot()}-like operation on the \var{filename} parameter, such
43+
that root is always relative to some safe ``sandbox'' area of the
44+
filesystem. In this case, the untrusted code would still see an
45+
\code{open()} function in its \code{__builtin__} module, with the same
46+
calling interface. The semantics would be identical too, with
47+
\code{IOError}s being raised when the supervisor determined that an
48+
unallowable parameter is being used.
49+
50+
Two modules provide the framework for setting up restricted execution
51+
environments:
52+
53+
\begin{description}
54+
55+
\item[rexec]
56+
--- Basic restricted execution framework.
57+
58+
\item[Bastion]
59+
--- Providing restricted access to objects.
60+
61+
\end{description}

‎Doc/librestricted.tex‎

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
\chapter{Restricted Execution}
2+
3+
In general, executing Python programs have complete access to the
4+
underlying operating system through the various functions and classes
5+
contained in Python's modules. For example, a Python program can open
6+
any file\footnote{Provided the underlying OS gives you permission!}
7+
for reading and writing by using the
8+
\code{open()} built-in function. This is exactly what you want for
9+
most applications.
10+
11+
There is a class of applications for which this ``openness'' is
12+
inappropriate. Imagine a web browser that accepts ``applets'', snippets of
13+
Python code, from anywhere on the Internet for execution on the local
14+
system. Since the originator of the code is unknown, it is obvious that it
15+
cannot be trusted with the full resources of the local machine.
16+
17+
\emph{Restricted execution} is the basic Python framework that allows
18+
for the segregation of trusted and untrusted code. It is based on the
19+
notion that trusted Python code (a \emph{supervisor}) can create a
20+
``padded cell' (or environment) of limited permissions, and run the
21+
untrusted code within this cell. The untrusted code cannot break out
22+
of its cell, and can only interact with sensitive system resources
23+
through interfaces defined, and managed by the trusted code. The term
24+
``restricted execution'' is favored over the term ``safe-Python''
25+
since true safety is hard to define, and is determined by the way the
26+
restricted environment is created. Note that the restricted
27+
environments can be nested, with inner cells creating subcells of
28+
lesser, but never greater, privledge.
29+
30+
An interesting aspect of Python's restricted execution model is that
31+
the attributes presented to untrusted code usually have the same names
32+
as those presented to trusted code. Therefore no special interfaces
33+
need to be learned to write code designed to run in a restricted
34+
environment. And because the exact nature of the padded cell is
35+
determined by the supervisor, different restrictions can be imposed,
36+
depending on the application. For example, it might be deemed
37+
``safe'' for untrusted code to read any file within a specified
38+
directory, but never to write a file. In this case, the supervisor
39+
may redefine the built-in
40+
\code{open()} function so that it raises an exception whenever the
41+
\var{mode} parameter is \code{'w'}. It might also perform a
42+
\code{chroot()}-like operation on the \var{filename} parameter, such
43+
that root is always relative to some safe ``sandbox'' area of the
44+
filesystem. In this case, the untrusted code would still see an
45+
\code{open()} function in its \code{__builtin__} module, with the same
46+
calling interface. The semantics would be identical too, with
47+
\code{IOError}s being raised when the supervisor determined that an
48+
unallowable parameter is being used.
49+
50+
Two modules provide the framework for setting up restricted execution
51+
environments:
52+
53+
\begin{description}
54+
55+
\item[rexec]
56+
--- Basic restricted execution framework.
57+
58+
\item[Bastion]
59+
--- Providing restricted access to objects.
60+
61+
\end{description}

0 commit comments

Comments
 (0)