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
