yahoo-eng-team team mailing list archive

[Jeremy Stanley <1970932@xxxxxxxxxxxxxxxxxx>]

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?

** Changed in: ossa
       Status: Incomplete => Invalid

** Description changed:

- 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

** Tags added: security

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1970932

Title:
  Domain Admins possibility for privilege escalation

Status in OpenStack Identity (keystone):
  New
Status in OpenStack Security Advisory:
  Invalid

Bug 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1970932/+subscriptions