Embedding a restricted python interpreter

[Rolf Magnus]

Hi,

I would like to embed a python interpreter within a program, but since that
program would be able to automatically download scripts from the internet,
I'd like to run those in a restricted environment, which basically means
that I want to allow only a specific set of modules to be used by the
scripts, so that it wouldn't be possible for them to remove files from the
hard drive, kill processes or do other nasty stuff.
Is there any way to do that with the standard python interpreter?

[Craig Ringer]

On Thu, 2005-01-06 at 23:05, Peter Maas wrote:

Craig Ringer schrieb: It would certainly be difficult to track all harmful code constructs.
But AFAIK the idea of a sandbox is not to look at the offending code
but to protect the offended objects: files, databases, URLs, sockets
etc. and to raise a security exception when some code tries to offend
them.
That's a good point. I'm not sure it's really all that different in the
end though, because in order to control access to those resources you
have to restrict what the program can do.

It'd probably be valid to implement a restricted mode at CPython level
(in my still-quite-new-to-the-Python/C-API view) by checking at the
"exit points" for important resources such as files, etc. I guess that's
getting into talk of something like the Java sandbox, though - something
Java proved is far from trivial to implement. Of course, CPython is just
a /tad/ smaller than Java ;-) .

Personally, I'd be worried about the amount of time it'd take and the
difficulty of getting it right. One wouldn't want to impart a false
sense of security.

My original point, though, was that I don't think you can use the
standard interpreter to create a restricted environment that will be
both useful and even vaguely secure. I'd be absolutely delighted if
someone could prove me wrong.
Python is a very well designed language but progress is made by
criticism not by satisfaction ;)

Heh, I'm hardly complacent... I run into quite enough problems,
especially with embedding and with the C API. Maybe one day I'll have
the knowledge - and the time - to have a chance at tackling them.

I'd love a restricted mode - it'd be great. I'm just not very optimistic
about its practicality.

--
Craig Ringer

[Dieter Maurer]

Doug Holton <a@b.c> writes on Thu, 06 Jan 2005 20:34:31 -0600:

...
Hi, there is a page on this topic here:
http://www.python.org/moin/SandboxedPython

The short answer is that it is not possible to do this with the
CPython, but you can run sandboxed code on other virtual machines,
such as Java's JVM with Jython, or .NET/Mono's CLR with Boo or
IronPython.

Zope contains a "restrictedPyth on" implementation.

It uses a specialized compiler that prevents dangerous bytecode operations
to be generated and enforces a restricted builtin environment.

[Paul Rubin]

Dieter Maurer <di****@handsha ke.de> writes:

It uses a specialized compiler that prevents dangerous bytecode operations
to be generated and enforces a restricted builtin environment.

Does it stop the user from generating his own bytecode strings and
demarshalling them?

[Dieter Maurer]

Paul Rubin <http://ph****@NOSPAM.i nvalid> writes on 08 Jan 2005 14:56:43 -0800:

Dieter Maurer <di****@handsha ke.de> writes:

It uses a specialized compiler that prevents dangerous bytecode operations
to be generated and enforces a restricted builtin environment.

Does it stop the user from generating his own bytecode strings and
demarshalling them?

Almost surely, I do not understand you:

In the standard setup, the code has no access to most
of Python's runtime library. Only a few selected modules
are deemed to be safe and can be imported (and used) in
"RestrictedPyth on". "marshal" or "unmarshal" are not considered safe.
Security Declaration can be used to make more modules importable -- but
then, this is an explicite decision by the application developper.

*If* the framework decided to exchange byte code between
user and iterpreter, then there would be no security at
all, because the interpreter is the standard interpreter
and security is built into the compilation process.
Of course, you should not step in *after* the secured step ;-)

Thus, "RestrictedPyth on" expects that the user sends
Python source code (and not byte code!), it compiles
this source code into byte code that enforces a strict
access and facility policy.
Dieter