I have added my proposal @ https://etherpad.openstack.org/api_policy_on_target.
Thanks, Arvind -----Original Message----- From: Henry Nash [mailto:hen...@linux.vnet.ibm.com] Sent: Wednesday, July 24, 2013 8:46 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [keystone] Extending policy checking to include target entities I think we should transfer this discussion to the etherpad for this blueprint: https://etherpad.openstack.org/api_policy_on_target I have summarised the views of this thread there already, so let's make any further comments there, rather than here. Henry On 24 Jul 2013, at 00:29, Simo Sorce wrote: > On Tue, 2013-07-23 at 23:47 +0100, Henry Nash wrote: >> ...the problem is that if the object does not exists we might not be able >> tell whether the use is authorized or not (since authorization might depend >> on attributes of the object itself)....so how do we know wether to lie or >> not? > > If the error you return is always 'Not Found', why do you care ? > > Simo. > >> Henry >> On 23 Jul 2013, at 21:23, David Chadwick wrote: >> >>> >>> >>> 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@lists.openstack.org >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-dev mailing list >>>>>> OpenStack-dev@lists.openstack.org >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> OpenStack-dev@lists.openstack.org >>>>> <mailto:OpenStack-dev@lists.openstack.org> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > Simo Sorce * Red Hat, Inc * New York > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
