scope of domain admin too broad in v3 policy sample
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Medium
|
Henry Nash | ||
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned | ||
OpenStack Security Notes |
Fix Released
|
Critical
|
Jamie Finnigan |
Bug Description
Using the policies in the new default policy.
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/
3) Change your domain_id to the id of the default domain (PATCH /v3/users/
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.
"cloud_admin": "rule:admin_
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).
Changed in ossa: | |
status: | New → Incomplete |
summary: |
- domain IDs should not be editable + scope of domain admin too broad in v3 policy sample |
Changed in keystone: | |
milestone: | none → icehouse-rc1 |
status: | New → In Progress |
Changed in keystone: | |
status: | In Progress → Fix Committed |
Changed in ossn: | |
assignee: | nobody → Jamie Finnigan (jamiefinnigan) |
Changed in ossn: | |
importance: | Undecided → Critical |
Changed in ossa: | |
status: | Incomplete → Won't Fix |
Changed in keystone: | |
status: | Fix Committed → Fix Released |
Changed in ossn: | |
status: | New → In Progress |
Changed in keystone: | |
milestone: | icehouse-rc1 → 2014.1 |
"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.