[Python-Dev] For sandboxing: alternative to crippling file()

[Brett Cannon]

I have gotten some questions from people about why cripple 'file' (and
probably 'socket' if they cared), asking whey I didn't just remove the
'file' built-in from built-ins.  Problem is that I still want to provide
some protection for files.

So an option I have been thinking of is making sure 'file' does not end up
in built-ins by just not inserting it into tstate->interp->builtins (see
Include/pystate.h to see what other fields there are; also will answer
Trent's question about how "heavy", roughly, interpreters are).  Then, there
can be a file delegator class that can, at the C level, store a reference to
the actual 'file' object that is open.  Finally, handling whether a path is
legal or not can be handled by open().

And the open() thing is the key here.  Guido always talks about how open()
should be treated more like a factory function that could some day return
the proper object based on its argument.  Well, perhaps we should start
doing that and add support for HTTP addresses and IP addresses.  Then the
file and networking settings can be viewed more as global settings to be
followed for file handling instead of specific restrictions placed on the
'file' and socket types.

My worry, as has been from the start, is containing 'file'.  The ``del
__builtins__`` bug for 'rexec' started me as skittish towards hiding stuff
from the built-in namespace.  And knowing how easy it tends to be to get at
objects and types in Python in general makes me worry even more about hiding
objects and types properly from people (within reason, of course; if you
want to allow blatent 'file' access we should be able to give it to you
somehow).  But perhaps removing 'file' from the builtin dict in the
PyInterpreterState state is enough to hide the type.

So, my question to python-dev, is:

1) Is removing 'file' from the builtins dict in PyInterpreterState (and
maybe some other things) going to be safe enough to sufficiently hide 'file'
confidently (short of someone being stupid in their C extension module and
exposing 'file' directly)?

2) Changing open() to return C-implemented delegate objects for files (and
thus won't type check, but this is Python so I am not worried about that too
much) and delegate socket objects for IP and URL addresses.


Basically, do people think doing this instead of modifying the 'file' object
directly and crippling is better and safer in terms of possible security
breach issues from implementing this?

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060629/415095e2/attachment-0001.htm