domain admin token will be treated as cloud admin

Bug #1651989 reported by Henry Nash on 2016-12-22
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
High
Henry Nash
OpenStack keystone charm
High
Frode Nordahl
keystone (Juju Charms Collection)
High
Frode Nordahl

Bug Description

The new capability of is_admin_project is currently only supported for projects. However, the existing code for token models will return is_admin_project as True if the attribute has not been set. Hence admin domain tokens might get interpreted as cloud admin tokens. This is currently masked by a bug in our policy samples that do not correctly check for is_admin_project.

Related branches

Changed in keystone:
assignee: nobody → Henry Nash (henry-nash)
status: New → In Progress
Changed in keystone:
assignee: Henry Nash (henry-nash) → Steve Martinelli (stevemar)

Marking as High importance as it is a security issue.

Changed in keystone:
importance: Undecided → High
Changed in keystone:
milestone: none → ocata-3
Changed in keystone:
assignee: Steve Martinelli (stevemar) → Henry Nash (henry-nash)
Lance Bragstad (lbragstad) wrote :

I know this is assigned to Henry, but do we have a fix floating around in Gerrit that didn't get linked?

Reviewed: https://review.openstack.org/411563
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=ef48072d94f780ebaacee8c3ddf02a68193fa74d
Submitter: Jenkins
Branch: master

commit ef48072d94f780ebaacee8c3ddf02a68193fa74d
Author: Steve Martinelli <email address hidden>
Date: Thu Dec 15 17:48:16 2016 -0800

    Fix cloud_admin rule and ensure only project tokens can be cloud admin

    The current rule fails to load with oslo.policy, the correct
    value used to determine the admin project for the cloud_admin should
    simply be: `is_admin_project:True`, since that is what is stored
    in oslo.context.

    This problem was masking a more serious issue that domain admin tokens
    could be misinterpreted as cloud admin tokens.

    Change-Id: I3ea562c01e06e6c519fdaec3ab6e1dac204ced71
    Closes-Bug: 1547684
    Closes-Bug: 1651989

Changed in keystone:
status: In Progress → Fix Released
James Page (james-page) on 2017-01-05
Changed in keystone (Juju Charms Collection):
status: New → Triaged
importance: Undecided → High
milestone: none → 17.01

This issue was fixed in the openstack/keystone 11.0.0.0b3 development milestone.

Frode Nordahl (fnordahl) wrote :

Using Mitaka Keystone with the v3 sample policy after commit of change https://review.openstack.org/411563 reverts the desired effects of https://review.openstack.org/#/c/242232/ and https://blueprints.launchpad.net/keystone/+spec/is-admin-project

A simple check is to attempt to list domains with a token scoped to the project and domain referenced by admin_project_name and admin_project_domain_name in /etc/keystone.conf and comparing results with a policy-file before and after the change.

The admin_domain_id place-holder is of course replaced with the actual uuid of the domain used in the test.

Before the change:
(keystone.common.controller): 2017-02-01 10:43:29,828 DEBUG RBAC: Adding query filter params ()
(keystone.common.controller): 2017-02-01 10:43:29,828 DEBUG RBAC: Authorizing identity:list_domains()
(keystone.common.controller): 2017-02-01 10:43:29,828 DEBUG RBAC: using auth context from the request environment
(keystone.policy.backends.rules): 2017-02-01 10:43:29,829 DEBUG enforce identity:list_domains: {'is_delegated_auth': False, 'access_token_id': None, 'user_id': u'47e2b6a7df204ebfb9e7245e97c2f345', 'roles': [u'Admin', u'Member'], 'user_domain_id': u'fe4e322a8a6942f1a8fe7de8167f0a6f', 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 'token': <KeystoneToken (audit_id=slIt9et9SWefByiRQV4Grw, audit_chain_id=slIt9et9SWefByiRQV4Grw) at 0x7fae3a9f1be0>, 'project_id': u'10f4dfe3abea45d4be6ee11a57934f89', 'trust_id': None, 'project_domain_id': u'fe4e322a8a6942f1a8fe7de8167f0a6f'}
(keystone.common.controller): 2017-02-01 10:43:29,830 DEBUG RBAC: Authorization granted

After the change:
(keystone.common.controller): 2017-02-01 10:45:26,059 DEBUG RBAC: Adding query filter params ()
(keystone.common.controller): 2017-02-01 10:45:26,060 DEBUG RBAC: Authorizing identity:list_domains()
(keystone.common.controller): 2017-02-01 10:45:26,060 DEBUG RBAC: using auth context from the request environment
(keystone.policy.backends.rules): 2017-02-01 10:45:26,060 DEBUG enforce identity:list_domains: {'is_delegated_auth': False, 'access_token_id': None, 'user_id': u'47e2b6a7df204ebfb9e7245e97c2f345', 'roles': [u'Admin', u'Member'], 'user_domain_id': u'fe4e322a8a6942f1a8fe7de8167f0a6f', 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 'token': <KeystoneToken (audit_id=Yo3-eosNTHqmjTfDGa9Hpw, audit_chain_id=Yo3-eosNTHqmjTfDGa9Hpw) at 0x7fb75cbaa3c8>, 'project_id': u'10f4dfe3abea45d4be6ee11a57934f89', 'trust_id': None, 'project_domain_id': u'fe4e322a8a6942f1a8fe7de8167f0a6f'}
(oslo_policy._cache_handler): 2017-02-01 10:45:26,061 DEBUG Reloading cached file /etc/keystone/policy.json
(oslo_policy.policy): 2017-02-01 10:45:26,070 DEBUG Reloaded policy file: /etc/keystone/policy.json
(keystone.common.wsgi): 2017-02-01 10:45:26,071 WARNING You are not authorized to perform the requested action: identity:list_domains

I believe this is a regression and the change is either incomplete or in error.

Frode Nordahl (fnordahl) on 2017-02-01
Changed in keystone (Juju Charms Collection):
assignee: nobody → Frode Nordahl (fnordahl)
Frode Nordahl (fnordahl) wrote :

Desired effect of is_admin_project is retained with this change in place on Keystone Ocata (tested with upstream master). Will investigate which implications (if any) this bug has for Mitaka and Newton and update accordingly.

Frode Nordahl (fnordahl) on 2017-02-02
tags: added: sts
tags: added: openstack
Frode Nordahl (fnordahl) wrote :

I have not found implications for Mitaka or Newton and they should keep using the old policy to retain desired functionality.

The policy change is indeed required for Ocata but the policy change is not sufficient for closing this hole and I have verified this with devstack running upstream master.

However, when attempting to verify the fix in a pre-existing in-development Ocata deployment I was unsuccessful and the problematic behaviour prevails regardless of policy change. I suspect that specific library versions are required along with this update to close the bug.

I will investigate this further and update the bug.

Frode Nordahl (fnordahl) wrote :

Second paragraph in previous comment was a bit bad worded, to be clear: devstack running upstream master works as it should with this policy change.

Third paragraph stands, for distributions there are other changes required to completely fix this issue.

Fix proposed to branch: master
Review: https://review.openstack.org/428759

Changed in keystone (Juju Charms Collection):
status: Triaged → In Progress
Frode Nordahl (fnordahl) wrote :

For the record this was resolved in upstream release 11.0.0.0b3 and verified in corresponding Ubuntu package python-keystone_11.0.0~b3-0ubuntu1_all.deb

no longer affects: cloud-archive

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 <email address hidden>
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
James Page (james-page) on 2017-02-23
Changed in charm-keystone:
assignee: nobody → Frode Nordahl (fnordahl)
importance: Undecided → High
status: New → Fix Committed
Changed in keystone (Juju Charms Collection):
status: Fix Committed → Invalid
James Page (james-page) on 2017-02-23
Changed in charm-keystone:
milestone: none → 17.02
James Page (james-page) on 2017-02-23
Changed in charm-keystone:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers