Domain Admins possibility for privilege escalation

[simon stephan]

Today we tested the Domain Admin functionality in Keystone, here is what we set up for our test:

- a new additional Domain called "test" next to default
- a new group for the domain admins of the new domain called "test-admins"
- a new user in the "test" domain that we added to the group "test-admins"
- a new project called "admin" in the "test" domain

We then just added a admin role for the "test-admins" group to the "test" domain:
openstack role add --domain test --group test-admins admin

After that the user was just able to list the users and projects of the new "test" domain and the permissions looked like we would expect for a Domain Admin.

We then were able to add the following role with the new domain admin user:
"openstack role add --group test-admins --project 8c4c0c4a01fe4c029a9e737713ee8267 admin"
(ID is from the "admin" project in the "test" domain)

After that we added the following lines to our rc file:
export OS_PROJECT_NAME="admin"
export OS_PROJECT_ID=8c4c0c4a01fe4c029a9e737713ee8267

With the admin role in the admin project of the new domain the user now is able to list the users of all domains, create new domains, and so on. For us it looks like we gained Cloud Admin privileges.

We tested this in Keystone Ussuri. And it also is reproducible in Wallaby.
We are unsure if that is actually a privilege escalation issue or if we have something that is configured wrong on our side. Thanks in advance for any help, we can provide further information if needed.

Regards
Simon

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential
solutions.

[Jeremy Stanley (fungi)]

Implementation of a consistent role-based access control model is still not complete across all OpenStack services, and was even less so when Ussuri and Wallaby were released. You can read the community goal here for details:

https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html

There are almost certainly existing bug reports we could mark this as a duplicate of, but I'll wait for one of the Keystone developers to confirm before switching it to public.

[simon stephan (simonstephan)]

Thanks for the reply. We are aware that this is not implemented to all components yet but our assumption was that it should work for keystone itself in Ussuri. And our tests also just involved requests to keystone.

[Gage Hugo (gagehugo)]

Jeremy is correct, the work to get to a consistent role-based access control model is still being worked on across OpenStack.

The "admin" project and "admin" role have a special meaning with RBAC in keystone, it is indeed a cloud admin role regardless of what domain they exist under. This is part of the old behavior that keystone had worked off of and it's something that was left over to avoid breaking users policies. If you are wanting to have more granular access I recommend renaming the project/role to something other than "admin", for example "test-admin" should show more of the expected results.

[Jeremy Stanley (fungi)]

Is there a preferred place in the Keystone documentation to point users about this potential pitfall, and can we do anything to make it more clear?

[Gage Hugo (gagehugo)]

There is this section in the docs[0], but right now it could probably be expanded on a bit better about this particular pitfall.

[0] https://docs.openstack.org/keystone/latest/admin/service-api-protection.html#admin

[simon stephan (simonstephan)]

Ok, i tested it with a different project name and with the admin role assigned in the project the domain-admin user is unable to manage users of the default domain.
However the problem still is that the domain-admin user is also able to create a project called admin in its own domain and with that he is still able to gain cloud-admin privileges.

I also think there should be a warning in the docs, as it could cause serious problems when it stays unnoticed by operators.

[Boris Bobrov (bbobrov)]

I tried to reproduce it and could not, but i would like to get to the bottom of this issue.

Warning: what i propose will disclose a lot about your cloud; please use a throwaway deployment if you are concerned. Could you please reproduce it again, with project name "admin", but this time make all requests with flag `--debug`? Something like `openstack project list --debug`. Please post all outputs to https://paste.opendev.org/ and post the links here.

[simon stephan (simonstephan)]

Hi Boris,

i just created a microstack deployment to verify it again. Please see the steps and also the debug output of the user list command that contains all users.

https://paste.opendev.org/show/814297/

Let me know if something else is needed.