[Python-Dev] rexec.py unuseable

John Roth newsgroups at jhrothjr.com
Mon Dec 15 15:37:28 EST 2003


"Luke Kenneth Casson Leighton" <lkcl at lkcl.net> wrote in message
news:mailman.162.1071515400.9307.python-list at python.org...
> On Mon, Dec 15, 2003 at 12:01:07PM -0600, Skip Montanaro wrote:
> >
> >     Luke> well, uhm, if [rexec]'s broken, why hasn't it been reverted to
the
> >     Luke> 2.0 code?
> >
> > My understanding was that in 2.0 it was also broken, but that
(relatively)
> > recent changes to Python made the breakage easier to exploit.

As I understand the issue, the "security" in rexec was
simply to pass a dictionary that prohibited access to
"unsafe" builtin functions. The discussion I've seen so
far is that it was never that difficult to break out of
the "jail," and it became even easier to break out
with the advanced features in 2.2 (particularly
new style classes.)

I've also seen comments that none of the developers
was interested in fixing it, and that the relatively
unsophisticated user would probably think it was
offering more "security" than it actually offered.

>From my admittedly parochial viewpoint, there are
basically four use cases for exec:

1. Interpreters such as the Python interpreter mode.

2. Evaluation of restricted expressions with the intention
of building an object structure that will then go into
additional application processing.

3 and 4. Creating classes, functions and methods to go
into a program, either (3) internally generated or
(4) externally input.

1 and 3 are clearly served by exec and eval.

2 and 4 were supposed to be served by rexec,
but rexec could not give a guarantee that a malicious
user couldn't break out of the 'jail.'

For myself, I'd prefer to see a facility where
the system would build an object structure
consisting *only* of standard objects,
including dicts, lists, tuples, strings, ints
and floats, and would reject anything else.
That is to say, no built-ins, no operators,
no object methods, no classes other than
the general use fundamental objects.
That's use case 2 above.

I don't currently have any need for
use case 4, and if I did, I'd feel a good
deal more secure building it myself
rather than trusting a general facility.

John Roth







More information about the Python-list mailing list