| 2022-04-29 12:00:22 |
simon stephan |
bug |
|
|
added bug |
| 2022-04-29 12:53:55 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2022-04-29 12:54:10 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2022-04-29 12:55:11 |
Jeremy Stanley |
description |
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 |
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed
(private) security vulnerabilities before their coordinated
publication by the OpenStack Vulnerability Management Team in the
form of an official OpenStack Security Advisory. This includes
discussion of the bug or associated fixes in public forums such as
mailing lists, code review systems and bug trackers. Please also
avoid private disclosure to other individuals not already approved
for access to this information, and provide this same reminder to
those who are made aware of the issue prior to publication. All
discussion should remain confined to this private bug report, and
any proposed fixes should be added to the bug as attachments. This
embargo shall not extend past 2022-07-28 and will be made
public by or on that date even if no fix is identified.
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 |
|
| 2022-04-29 12:55:23 |
Jeremy Stanley |
bug |
|
|
added subscriber Keystone Core security contacts |
| 2022-04-29 14:27:33 |
Gage Hugo |
information type |
Private Security |
Public |
|
| 2022-04-29 14:36:58 |
Jeremy Stanley |
ossa: status |
Incomplete |
Invalid |
|
| 2022-04-29 14:37:11 |
Jeremy Stanley |
description |
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed
(private) security vulnerabilities before their coordinated
publication by the OpenStack Vulnerability Management Team in the
form of an official OpenStack Security Advisory. This includes
discussion of the bug or associated fixes in public forums such as
mailing lists, code review systems and bug trackers. Please also
avoid private disclosure to other individuals not already approved
for access to this information, and provide this same reminder to
those who are made aware of the issue prior to publication. All
discussion should remain confined to this private bug report, and
any proposed fixes should be added to the bug as attachments. This
embargo shall not extend past 2022-07-28 and will be made
public by or on that date even if no fix is identified.
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 |
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 |
|
| 2022-04-29 14:37:28 |
Jeremy Stanley |
tags |
|
security |
|
| 2022-05-03 19:05:41 |
Marc Vorwerk |
bug |
|
|
added subscriber Marc Vorwerk |
