[Python-Dev] Re: Capabilities

[Jim Fulton]

Samuele Pedroni wrote:
> From: "Samuele Pedroni" <pedronis@bluewin.ch>
> 
>>From: "Jim Fulton" <jim@zope.com>
>>
>>>For example, you can't proxy exceptions without
>>>breaking exception handling. In Zope, we rely on restricted execution to
>>
>>prevent
>>
>>>certian kinds of introspection on exceptions and exception classes.  In
> 
> Zope,
> 
>>we
>>
>>>also don't proxy None, because None is usually checked for identity. We
> 
> also
> 
>>don't
>>
>>>proxy strings, and numbers.
>>>
>>
>>That was a question I was asking myself about proxies: exception handling.
>>But I never had the time to play with it to check.
>>
>>Does that mean that restricted code can get unproxied instances of classic
>>classes as caught exceptions?
> 
> 
> maybe the question was unclear,

I think it was clear.

 > but it was serious, what I was asking is
> whether some restricted code can do:
> 
> try:
>   deliberate code to force exception
> except Exception,e:
>  ...
> 
> so that e is caught unproxied.

Right. e is caught unproxied.


 > Looking at zope/security/_proxy.c it seems this
> can be the case...

Yes,

> then to be (likely) on the safe side, all exception class definitions for
> possible e classes: like e.g.
> 
> class MyExc(Exception):
>     ...
> 
> 
> ought to be executed _in restricted mode_, or be "trivial/empty": something
> like
> 
> class MyExc(Exception):
>     def __init__(self, msg):
>         self.message = msg
>         Exception.__init__(self, msg)
> 
>     def __str__(self):
>         return self.message
>
> is already too much rope.

I'm not sure if you are saying that this examples is "trivial/empty"
or not.  It seems that yuo are saying that it is not trvial enough.
If so, why?


> Although it seems not to have the "nice" two-level-of-calls behavior of Bastion
> instances, an unproxied instance of MyExc if MyExc was defined outside of
> restricted execution, can be used to break out of restricted execution.

How can it be used to break out of restricted execution?

I see three risks:

   1. The exception provides methods to do harmful things,
      such as create side effects or provide access to data outside
      the exception.

   2. The exception creates data that needs to be protected.  For example
      Zope uses a NotFoundError exception taht contains an object being searched.

   3. The exception methods meta data provide access to module globals.

Risk 1 needs to be mitigated through proper exception design. Exceptions
need to be limited in what their methods do.  This is a bit brittle, but
all standard exceptions have this property.

Risk 2 is mitigated by proxying exception instance data.  Proxies can do this.
This is what we've decided to do, although we haven't implemented it yet.

Risk 3 is mitigated by restricted execution.

Have I missed anything?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org