[Zope-dev] Re: Security audit introduced problem in PageTemplates/Expression.py

[Jim Fulton]

Dieter Maurer wrote:
> Jim Fulton wrote at 2004-1-16 18:54 -0500:
> 
>>...
>>
>>>  For security checks, the accessed object should be the driving factor
>>>  and not the particular way the access is made.
>>
>>Well, sorry, that's not what this is about.  We are talking about what
>>to do when accessing objects without roles.  The ability to take
>>the name into account is a feature that only makes sense for named, ie
>>attribute access, imo.
> 
> 
> "item" is a blurred term in Python:
> 
>   As you know, it refers both to sequences (indexed via integers)
>   and mappings (indexed via something hashable; often a string).

I don't see this as blurred at all.  A sequence is, mathematically,
a special case of a mapping.

> When some mechanism checks whether access should be granted to
> individual items in a mapping, this mechanism will (almost surely) need
> to know the key used in the access -- and I do not see any reason
> why it should not be informed about the key.

I question whether there is a need to check "whether access should
be granted to individual items in a mapping".

I suggest that such flexibility makes the security system needlessly
complex.

> I do not argue that the handler registered with "setDefaultAccess"
> should be used for "__getitem__" access checking.

Cool

> However, when it is called (as it seems to be the case),
> then it should be called consistently and provide
> as much information as useful -- this includes information
> about both arguments to the "__getitem__" method.

Ah, so you are arguing that the handler should simply not
be called for item access. I can buy that.  I don't think
that would make Stuart happy though. :)

> 
> Even more essential for security related issues:
> 
>   A precise description when what security related functions
>   are called with what arguments.
> 
> The current state in this respect is far from optimal.
> Special points of my concern:

I assume that you are refering to the security policy.

> 
>   *  I never saw a description of the difference between the
>      "accessed" and "container" parameters to "validate".
> 
>   *  I never saw a description for the three way outcome
>      of "validate": "0", "1" and "raise Unauthorized".
>      Why in hell is "unauthorized" encoded sometimes
>      as "return 0" and sometimes as "raise Unauthorited".
>      Looking at the code, I see that "accessed/container"
>      has to do with this destinction. However, as
>      "accessed/container" is unspecified, this does not clarify
>      much.

These are valid points. This should be documented
much better than it has been. I'll note that both of the
things you ask about relate to no-longer used features
of the security policy.

I'll make an attempt at a brief
explanation:

- The *original* reason for the accessed and validate parameters was
   to permit the distinction between acquired and non-acquired
   attributes.  As a comment in the security policy code notes,
   we no-longer pay any attention to the accessed argument.

- The *original* use for the 0 return value from the security
   policy was to suggest that, although access to the value provided
   was unauthorized, the application might provide a different value
   that would be.  This was to support a questionable feature of
   trying to acquire another value of the first value found through
   acquisition was unauthorized.  The current Zope security policy
   never returns 0.

Much of the complexity in the Zope 2 security policy has to do with:

- The fact that the security system is based on looking at
   assertions for values, and

- The fact that we can't make assertions on immutable values
   (e.g. strings).

>Certainly, you have to think about how you provide access to data.
>>Lots of data we provide access to has no security assertions of it's
>>own.
> 
> 
> Maybe, we should change this for Zope 3?

In Zope 3 (and, I hope 2.9), it will be easier to make security assertions
about things you can't make assertions about now.

The fundamental change in Zope 3 is that we make assertions
about *names*, not values.  This makes it possible to talk about
access to attributes whose values are strings. Essentially, we
are placing the resytictions on the *access*, not the values.


> It would have been possible for Zope 2 since a long time --
> but tightening security has high risk to break many applicitation
> (as the latest security fixes demonstrated again).

A mistake in Zope 2, we've made the mistake of trying to
provide backward compatability at almost any cost.  This has led to
parts of the framework being far more complicated than it should
be.

In the future, we've got to do a better job of managing change
so that we can clean things up.

> 
>>Think of accessor methods that return data. If data needs to be
>>protected, you need to think about the access methods you provide.
>>
>>In the future, item access will work like this:
>>
>>    You will be able to protect __setitem__ operations.  Once
>>    someone can use setitem, they can access any key.  The value
>>    stored with that key may have pretections of it's own, or not.
>>    That's a matter of application design.
> 
> 
> Fine!
> 
> However, security related rules are important enough that
> they deserve thourough and prominent specification/documentation.

Yup. We are certainly trying to do a good job of this in Zope 3.
I hope that, in the near furture, we can merge some aspects of the
Zope 2 and Zope 3 security architectures.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org