rexec questions

Alex Martelli aleaxit at yahoo.com
Mon Aug 6 12:18:24 EDT 2001


"Roman Suzi" <rnd at onego.ru> wrote in message
news:mailman.996864975.20659.python-list at python.org...
    ...
> >>> rexec.RExec.ok_builtin_modules
    ...
> I thought that it could import ONLY rexec.RExec.ok_builtin_modules!

The only builtin-modules (i.e., modules written in C) that
the untrusted code can import are those there listed.

> (Though, popen2.os is restricted correctly). Is rexec smarter these
> days or does it restrict loading only dynamic (written in C) modules?

That's the semantic of ok_builtin_modules.

But note that you CAN subclass rexec.RExec and tweak things!
For example, most simply, use a different ok_path and only
modules in the directories you list in ok_path will be importable
by untrusted code r_exec'd by instances of your subclass.
Or even, override method r_import and you can define your
own importing policies.


> And also, is ther any way to restrict programs from contacting
> hosts outside some list? If I understood correctly, networking
> in rexec is all-or-nothing...

Right, but, again, you can easily wrap the socket module to
control what happens -- put your own wrapper in a directory
on the ok_path, make sure it's also in sys.modules['socket']
so that trusted Python-coded networking modules that may
be called from untrusted code will also use your wrapper when
connecting sockets, and there you are.

rexec is something of a 'sandbox construction toolkit' (together
with Bastion) rather than a finished piece of work -- probably
because there isn't much current interest in controlled execution
of untrusted Python code, so rexec didn't (I think) mature much
after work on Grail more or less stopped.  But there are surely
other interesting applications for sandboxes for untrusted code,
so it may be time to design and implement a rexec2 successor,
building upon rexec to add easier customization of security
(controlled imports of non-builtin modules too, connections
only to hosts on a trusted list, whatever...).


Alex






More information about the Python-list mailing list