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

[Dieter Maurer]

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).

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 do not argue that the handler registered with "setDefaultAccess"
should be used for "__getitem__" access checking.

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.


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 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.

>>   When we do not get this consistent, we open new hidden
>>   security holes (as one must always think: can this
>>   same object be accessed also in a different way
>>   and how have I to secure this way).
>
>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?

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).

> 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.

-- 
Dieter