Author: Armin Rigo <[email protected]>
Branch:
Changeset: r68124:471b407d8d5b
Date: 2013-11-14 23:19 +0100
http://bitbucket.org/pypy/pypy/changeset/471b407d8d5b/
Log: Rewrite the introduction, linking to SECCOMP and to Victor Stinner's
mail on python-dev about pysandbox.
diff --git a/pypy/doc/sandbox.rst b/pypy/doc/sandbox.rst
--- a/pypy/doc/sandbox.rst
+++ b/pypy/doc/sandbox.rst
@@ -4,26 +4,36 @@
Introduction
------------
-It is possible to compile a version of pypy-c that runs
-fully "virtualized", i.e. where an external process controls all
-input/output. Such a pypy-c is a secure sandbox: it is safe to run
-any untrusted Python code with it. The Python code cannot see or
-modify any local file except via interaction with the external
-process. It is also impossible to do any other I/O or consume more
-than some amount of RAM or CPU time or real time. This works with no
-OS support at all - just ANSI C code generated in a careful way. It's
-the kind of thing you could embed in a browser plug-in, for example
-(it would be safe even if it wasn't run as a separate process,
-actually).
+PyPy offers sandboxing at a level similar to OS-level sandboxing (e.g.
+SECCOMP_ on Linux), but implemented in a fully portable way. To use it,
+a (regular, trusted) program launches a subprocess that is a special
+sandboxed version of PyPy. This subprocess can run arbitrary untrusted
+Python code, but all its input/output is serialized to a stdin/stdout
+pipe instead of being directly performed. The outer process reads the
+pipe and decides which commands are allowed or not (sandboxing), or even
+reinterprets them differently (virtualization). A potential attacker
+can have arbitrary code run in the subprocess, but cannot actually do
+any input/output not controlled by the outer process. Additional
+barriers are put to limit the amount of RAM and CPU time used.
-For comparison, trying to plug CPython into a special virtualizing C
-library is not only OS-specific, but unsafe, because one of the known
-ways to segfault CPython could be used by an attacker to trick CPython
-into issuing malicious system calls directly. The C code generated by
+Note that this is very different from sandboxing at the Python language
+level, i.e. placing restrictions on what kind of Python code the
+attacker is allowed to run (why? read about pysandbox_).
+
+.. _SECCOMP: http://code.google.com/p/seccompsandbox/wiki/overview
+.. _pysandbox:
https://mail.python.org/pipermail/python-dev/2013-November/130132.html
+
+Another point of comparison: if we were instead to try to plug CPython
+into a special virtualizing C library, we would get a result
+that is not only OS-specific, but unsafe, because CPython can be
+segfaulted (in many ways, all of them really, really obscure).
+Given enough efforts, an attacker can turn almost any
+segfault into a vulnerability. The C code generated by
PyPy is not segfaultable, as long as our code generators are correct -
-that's a lower number of lines of code to trust. For the paranoid, in
-this case we also generate systematic run-time checks against buffer
-overflows.
+that's a lower number of lines of code to trust. For the paranoid,
+PyPy translated with sandboxing also contains systematic run-time
+checks (against buffer overflows for example)
+that are normally only present in debugging versions.
.. warning::
_______________________________________________
pypy-commit mailing list
[email protected]
https://mail.python.org/mailman/listinfo/pypy-commit
