[Python-Dev] Capabilities

[Paul Prescod]

Guido van Rossum wrote:
>>How is the implementation of "open" provided by the trusted code to
>>the untrusted code?  Is it possible to provide a different "open"
>>implementation to different "instances" of the zipfile module?  (I
>>think not, as there is no such thing as "a different instance of a
>>module", but perhaps you could have two rexec "workspaces" each of
>>which has a zipfile module with a different "open"?)
> 
> 
> To the contrary, it is very easy to provide code with a different
> version of open().  E.g.:
> 
>   # this executes as trusted code
>   def my_open(...):
>     "open() variant that only allows reading"
>   my_builtins = {"len": len, "open": my_open, "range": range, ...}
>   namespace = {"__builtins__": my_builtins}
>   exec "..." in namespace

That's fair enough, but why is it better for the "protection domain" to 
be an invoked "workspace" instead of an object?

Think of it from a software engineering point of view: you're proposing 
that the right way to manage security is to override more-or-less global 
variables. Zooko is proposing that you pass the capabilities each method 
needs to that method. i.e. standard structured programming.

Let's say that untrusted code wants access to the socket module. The 
surrounding code wants to tame it to prevent socket connections to 
certain IP addresses. I think that in the rexec model, the surrounding 
application would have to go in and poke "safe" versions of the 
constructor into the module. Or they would have to disallow access to 
the module altogether and provide an object that tamed module 
appropriately. The first approach is kind of error prone. The second 
approach requires the untrusted code to use a model of programming that 
is very different than "standard Python."

If we imagined a Python with capabilities were built in deeply, the 
socket module would be designed to be tamed. By default it would have no 
authority at all except that which is passed in. The authority to 
contact the outside world would be separate from all of the other useful 
stuff in the socket module and socket class. I'm not necessarily 
advocating this kind of a change to the Python library...

  Paul Prescod