Secure embedding of Python

Martin von Loewis loewis at
Fri Sep 28 09:50:29 CEST 2001

tordj at (Tord Jansson) writes:

> 2. Lock out the use of any other modules. If not possible in any other
> way I can always scan through the script before execution for any
> inclusion of other modules.

It is easily possible. The only danger comes from C modules; Python
modules cause no security risk, since they eventually have to perform
all their actions through C modules.

By restricting the list of C modules (and builtins), you effectively
and reliably limit what Python code can do. If you look for several
levels of access, you need the rexec module, which allows to further
limit the set of available functions.

To limit the list of available C modules, you best link every module
that you want to offer into your application, and remove the
possibility for dynamically loading extension modules. To do that,
make sure that HAVE_DYNAMIC_LOADING is not defined.

> 1. Will this approach effectively lock out access to file-functions
> etc or are some dangerous functionality built into the interpreter
> itself?

Yes, you need to disable the open function. That may require changes
to builtinsmodule.

> 2. Is some necessary functionality (memory allocation for
> example)placed in modules which I therefore will have to include?

Yes. You cannot disable the sysmodule and the builtins module. If you
need gc, you must include the gcmodule, and if you need threads, you
must include the threadmodule. It is also advisable to include the
strings module and the _sre module.

> 3. Is there any way to access (read and/or write) raw memory in
> Python which might be hard to lock out? Something similar to just
> giving a pointer a value and reading from there in C/C++? Writing
> outside its own array structures?

That is not possible. With the mmap module, you can write to raw
memory, but not with random access to the address space.


More information about the Python-list mailing list