[openstack-dev] [keystone] Extending policy checking to include target entities
d.w.chadwick at kent.ac.uk
Tue Jul 23 20:23:06 UTC 2013
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
> 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:
>> and ones like this:
>> 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.
>>> On 23/07/2013 16:40, Henry Nash wrote:
>>>> As part of bp
>>>> 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.
>>>> 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
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev