[Python-Dev] Re: Whither rexec?

["Martin v. Löwis"]

Kevin Jacobs wrote:
>   It has been said that the previous rexec functionality was ad hoc and
>   brittle, and many better solutions are possible.  What better alternatives
>   exist in terms of features offered, overall runtime performance, ease of
>   maintenance, and validation?

I disagree with that statement. The approach taken by rexec is very 
straight forward, and, in principle, allows to impose arbitrary 
functional restrictions on untrusted code. Non-functional restrictions 
(code has to observe limitations in resource usage, such as computing 
time, memory consumption, or number of open files) are not easily 
implemented with rexec. I believe that any extension to provide such 
restrictions also would be orthogonal to rexec.

So anybody working on this should see how rexec could be enhanced. IMO, 
of course.

>   Proxy objects              -- making unsafe objects safe(r)

I think the really tricky part today is usage of the type() builtin 
(i.e. access to an object's __class__ attribute). The new problem is 
that types are now callable.

On one hand, you cannot hand out the true type objects to untrusted 
code, since they could use them to overcome the limitations. On the 
other hand, if the untrusted code merely uses the type objects for 
testing type membership, such code should continue to work.

So you either need a way to disable calls to type objects, or you need 
proxy type objects around the builtin types. For proxy types, some types 
could be considered safe (e.g. int, str, unicode); others would need 
proxies (the file type in particular).

>   Restricted introspection   -- limiting the amount of information
>                                 obtainable from exposed objects and
>                                 environment

Can somebody please explain how this is different from restricted 
environments? I.e. why would one restrict introspection in general, as 
long as you can't obtain information about the system?

>   Tainting                   -- tracking trusted status of objects

This is clearly out of scope of rexec, and, IMO, not relevant for 
untrusted code. Tainting is about processing untrusted data by trusted code.

>   Security policy management -- Configuration of how security mechanisms are
>                                 applied

I think rexec is quite flexible here, giving or denying access on a 
per-function basis (and allowing to provide wrappers for functions which 
must be restricted depending on the set of arguments).

Regards,
Martin