Open Stack

Reviewed:  https://review.openstack.org/428759
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=67034c4db8613e8cead5e5839edbecf040b4fb91
Submitter: Jenkins
Branch:    master

commit 67034c4db8613e8cead5e5839edbecf040b4fb91
Author: Frode Nordahl <frode.nordahl at canonical.com>
Date:   Tue Jan 10 08:50:28 2017 +0100

    Update policy.json for Ocata
    
    Refresh v2 and v3 portion of policy.json from upstream keystone
    repository @ commit
    d4a890a6c8bd6927e229f4b665a982a51c130073
    
    Add functional tests to verify effect of policy
    
    Update functional tests to use keystone_configure_api_version
    from charm-helpers
    
    Update functional tests to correctly validate cinder services
    when openstack release >= ocata
    
    Enable functional test for ocata, set appropriate cinder
    configuration.
    
    Change-Id: Idf07ff3a7c9d7e7eb30792719541319ab3426a41
    Closes-Bug: 1651989
    Closes-Bug: 1649446


** Changed in: keystone (Juju Charms Collection)
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1649446

Title:
  Non-Admin Access to Revocation Events

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in keystone package in Juju Charms Collection:
  Fix Committed

Bug description:
  With the default Keystone policy any authed user can list all revocation events for the cluster:
  https://github.com/openstack/keystone/blob/master/etc/policy.json#L179

  This can be done by directly calling the API as such:
  curl -g -i -X GET http://localhost/identity/v3/OS-REVOKE/events -H "Accept: application/json" -H "X-Auth-Token: <non_admin_token_goes_here>"

  and this will provide you with a normal revocation event list (see
  attachment).

  This will allow a user to over time collect a list of user_ids and
  project_ids. The project_ids aren't particularly useful, but the
  user_ids can be used to lock people of of their accounts. Or if rate
  limiting is not setup (a bad idea), or somehow bypassed, would allow
  someone to brute force access to those ids.

  Knowing the ids is no worse than knowing the usernames, but as a non-
  admin you shouldn't have access to such a list anyway.

  It is also worth noting that OpenStack policy files are rife with
  these blank policy rules, not just Keystone. Some are safe and
  intended to be accessible by any authed user, others are checked at
  the code layer, but there may be other rules that are unsafe to expose
  to any authed user and as such should actually default to
  "rule:admin_required" or something other than blank.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1649446/+subscriptions