scope of domain admin too broad in v3 policy sample

[Udi Kalifon]

Using the policies in the new default policy.v3cloudsample.json file, a domain admin can easily elevate himself and become the cloud admin:

1) Get a token of a domain admin (a user with 'admin' role on any domain other that the default domain which is the cloud admin's domain)
2) Grant yourself the admin role on the default domain which is the domain of the cloud admin (PUT /v3/domains/default/user/<your_id_here>/roles/<admin_role_id>
3) Change your domain_id to the id of the default domain (PATCH /v3/users/<your_id_here> -d '"{user": {"domain_id": "default"}}'
4) Get a new token scoped to the default domain

==> You are now the cloud admin

It is expected that step number 2 should fail. Admins should be able to grant roles only on their domain and their projects, not on other projects. Otherwise, it is as if they are not really scoped at all.

NOTE: I am using the default policy.v3cloudsample.json file as is, unchanged. I only defined the domain of the cloud admins to be the default domain by editing this rule:
    "cloud_admin": "rule:admin_required and domain_id:default",

I think that the default policy file should be changed to prevent administrators' ability to grant roles on objects of foreign domains (with the exception of admins in the domain defined by the cloud_admin rule, of course).

[Dolph Mathews (dolph)]

"policy.v3cloudsample.json" is *not* the default, particularly because it offers no tangible benefit over the actual default (policy.json) for this use case. Neither policy file is capable of reflecting scoped "admin-ness", period.

[Adam Young (ayoung)]

This is slightly different from bug #968696 as it specifically referes to isues with the sample config that we are telling people is "better".

[Adam Young (ayoung)]

The problem is that that a userid is associated with a domain, and that should not be editable. That is a security issue regardless.

In addition, only a domain admin should be able to assign roles for things inside their domains. Role assignments are owned by the assignment domain, not the identity domain

[Dolph Mathews (dolph)]

When v3 was designed, the mutability of a user's / group's domain_id was specifically discussed, and we decided it was an implementation detail that we could work out later given the lack of a use case at the time to guide a decision one way or another. In retrospect, I would have preferred to make it immutable from the beginning (it's easier to make it mutable later, than to make it immutable now).

If there's a solution to make it immutable through configurable policy, I'd be interested in seeing it. If not, it'd be worth considering a simpler solution to hardcode it as immutable.

[Henry Nash (henry-nash)]

Actually, while I agree that v3 sample policy file is not the default, this report highlights an issue: A recent modification to the v3 sample police file introduced a bug that enables 2), and potentially 3) as well. It should not be possible to assign a role on a different domain unless you have domain or cloud admin rights to that domain. The modification tried to simplify the checking logic, but, I think, oversimplified it:

Change responsible: https://github.com/openstack/keystone/commit/0496466821c1ff6e7d4209233b6c671f88aadc50#diff-c391c57d187de2cc248667c704e28ac3
-

[Henry Nash (henry-nash)]

(Apologies, please disregard the last comment….I posted this to the wrong bug report)

[Henry Nash (henry-nash)]

(actually please disregard my disregard message :-)…..this is (one of) the relevant bugs my comment relates to).

[Jeremy Stanley (fungi)]

If this is only likely to get "fixed" in configuration samples, we probably shouldn't leave the bug report private while that work is going on. Also it doesn't sound like something the VMT is likely to release an advisory on (though the OSSG may be interested in documenting the risks represented in the sample, so we can ping them if this really is just a sample config issue).

[Udi Kalifon (ukalifon)]

We plan to open a public bug to track this issue in our bugzilla downstream.
Is everyone OK with that?

[Dolph Mathews (dolph)]

Udi: wait for this bug to be opened publicly first.

[Thierry Carrez (ttx)]

Udi: bug is now public, feel free to push downstream

[Thierry Carrez (ttx)]

Adding ossn task as the OSSG might want to publish a note about it once it's fixed.

[Dolph Mathews (dolph)]

Fix in keystone: https://review.openstack.org/#/c/79897/

[Henry Nash (henry-nash)]

HI Thierry

I think that actually did fix this, with the patch I submitted.

Henry
On 24 Mar 2014, at 15:25, Thierry Carrez <email address hidden> wrote:

> ** Changed in: ossa
> Status: Incomplete => Won't Fix
>
> --
> You received this bug notification because you are a bug assignee.
> Matching subscriptions: Keystone-Bugs
> https://bugs.launchpad.net/bugs/1287219
>
> Title:
> scope of domain admin too broad in v3 policy sample
>
> Status in OpenStack Identity (Keystone):
> Fix Committed
> Status in OpenStack Security Advisories:
> Won't Fix
> Status in OpenStack Security Notes:
> New
>
> Bug description:
> Using the policies in the new default policy.v3cloudsample.json file,
> a domain admin can easily elevate himself and become the cloud admin:
>
> 1) Get a token of a domain admin (a user with 'admin' role on any domain other that the default domain which is the cloud admin's domain)
> 2) Grant yourself the admin role on the default domain which is the domain of the cloud admin (PUT /v3/domains/default/user/<your_id_here>/roles/<admin_role_id>
> 3) Change your domain_id to the id of the default domain (PATCH /v3/users/<your_id_here> -d '"{user": {"domain_id": "default"}}'
> 4) Get a new token scoped to the default domain
>
> ==> You are now the cloud admin
>
> It is expected that step number 2 should fail. Admins should be able
> to grant roles only on their domain and their projects, not on other
> projects. Otherwise, it is as if they are not really scoped at all.
>
> NOTE: I am using the default policy.v3cloudsample.json file as is, unchanged. I only defined the domain of the cloud admins to be the default domain by editing this rule:
> "cloud_admin": "rule:admin_required and domain_id:default",
>
> I think that the default policy file should be changed to prevent
> administrators' ability to grant roles on objects of foreign domains
> (with the exception of admins in the domain defined by the cloud_admin
> rule, of course).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/keystone/+bug/1287219/+subscriptions
>

[Thierry Carrez (ttx)]

@Henry: agreed, I'm just closing the OSSA task (meaning we won't be releasing a

[Thierry Carrez (ttx)]

....security advisory for this.

[Henry Nash (henry-nash)]

ahh, sorry, right - understand.

Henry
On 25 Mar 2014, at 10:31, Thierry Carrez <email address hidden> wrote:

> @Henry: agreed, I'm just closing the OSSA task (meaning we won't be
> releasing a
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1287219
>
> Title:
> scope of domain admin too broad in v3 policy sample
>
> Status in OpenStack Identity (Keystone):
> Fix Committed
> Status in OpenStack Security Advisories:
> Won't Fix
> Status in OpenStack Security Notes:
> New
>
> Bug description:
> Using the policies in the new default policy.v3cloudsample.json file,
> a domain admin can easily elevate himself and become the cloud admin:
>
> 1) Get a token of a domain admin (a user with 'admin' role on any domain other that the default domain which is the cloud admin's domain)
> 2) Grant yourself the admin role on the default domain which is the domain of the cloud admin (PUT /v3/domains/default/user/<your_id_here>/roles/<admin_role_id>
> 3) Change your domain_id to the id of the default domain (PATCH /v3/users/<your_id_here> -d '"{user": {"domain_id": "default"}}'
> 4) Get a new token scoped to the default domain
>
> ==> You are now the cloud admin
>
> It is expected that step number 2 should fail. Admins should be able
> to grant roles only on their domain and their projects, not on other
> projects. Otherwise, it is as if they are not really scoped at all.
>
> NOTE: I am using the default policy.v3cloudsample.json file as is, unchanged. I only defined the domain of the cloud admins to be the default domain by editing this rule:
> "cloud_admin": "rule:admin_required and domain_id:default",
>
> I think that the default policy file should be changed to prevent
> administrators' ability to grant roles on objects of foreign domains
> (with the exception of admins in the domain defined by the cloud_admin
> rule, of course).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/keystone/+bug/1287219/+subscriptions
>

[Jamie Finnigan (jamiefinnigan)]

OSSN: https://review.openstack.org/#/c/85441/

[Nathan Kinder (nkinder)]

Published as OSSN-0010 to the following locations:

  <email address hidden>
  <email address hidden>
  https://wiki.openstack.org/wiki/OSSN/OSSN-0010