Open Stack

On 23/07/2013 19:02, Henry Nash wrote:
> One thing we could do is:
>
> - Return Forbidden or NotFound if we can determine the correct answer
> - When we can't (i.e. the object doesn't exist), then return NotFound
> unless a new config value 'policy_harden' (?) is set to true (default
> false) in which case we translate NotFound into Forbidden.

I am not sure that this achieves your objective of no data leakage 
through error codes, does it?

Its not a question of determining the correct answer or not, its a 
question of whether the user is authorised to see the correct answer or not

regards

David
>
> Henry
> On 23 Jul 2013, at 18:31, Adam Young wrote:
>
>> On 07/23/2013 12:54 PM, David Chadwick wrote:
>>> When writing a previous ISO standard the approach we took was as follows
>>>
>>> Lie to people who are not authorised.
>>
>> Is that your verbage?  I am going to reuse that quote, and I would
>> like to get the attribution correct.
>>
>>>
>>> So applying this approach to your situation, you could reply Not
>>> Found to people who are authorised to see the object if it had
>>> existed but does not, and Not Found to those not authorised to see
>>> it, regardless of whether it exists or not. In this case, only those
>>> who are authorised to see the object will get it if it exists. Those
>>> not authorised cannot tell the difference between objects that dont
>>> exist and those that do exist
>>
>> So, to try and apply this to a semi-real example:  There are two types
>> of URLs.  Ones that are like this:
>>
>> users/55FEEDBABECAFE
>>
>> and ones like this:
>>
>> domain/66DEADBEEF0000/users/55FEEDBABECAFE
>>
>>
>> In the first case, you are selecting against a global collection, and
>> in the second, against a scoped collection.
>>
>> For unscoped, you have to treat all users as equal, and thus a 404
>> probably makes sense.
>>
>> For a scoped collection we could return a 404 or a 403 Forbidden
>> <https://en.wikipedia.org/wiki/HTTP_403> based on the users
>> credentials:  all resources under domain/66DEADBEEF0000  would show up
>> as 403s regardless of existantce or not if the user had no roles in
>> the domain 66DEADBEEF0000.  A user that would be allowed access to
>> resources in 66DEADBEEF0000  would get a 403 only for an object that
>> existed but that they had no permission to read, and 404 for a
>> resource that doesn't exist.
>>
>>
>>
>>
>>>
>>> regards
>>>
>>> David
>>>
>>>
>>> On 23/07/2013 16:40, Henry Nash wrote:
>>>> Hi
>>>>
>>>> As part of bp
>>>> https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target
>>>> I have uploaded some example WIP code showing a proposed approach
>>>> for just a few API calls (one easy, one more complex). I'd
>>>> appreciate early feedback on this before I take it any further.
>>>>
>>>> https://review.openstack.org/#/c/38308/
>>>>
>>>> A couple of points:
>>>>
>>>> - One question is on how to handle errors when you are going to get
>>>> a target object before doing you policy check.  What do you do if
>>>> the object does not exist?  If you return NotFound, then someone,
>>>> who was not authorized  could troll for the existence of entities by
>>>> seeing whether they got NotFound or Forbidden. If however, you
>>>> return Forbidden, then users who are authorized to, say, manage
>>>> users in a domain would aways get Forbidden for objects that didn't
>>>> exist (since we can know where the non-existant object was!).  So
>>>> this would modify the expected return codes.
>>>>
>>>> - I really think we need some good documentation on how to bud
>>>> keystone policy files.  I'm happy to take a first cut as such a
>>>> thing - what do you think the right place is for such documentation
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>