This change addresses several issues in the creation and use of EC2/S3
credentials with keystone tokens.
1. Disable altering credential owner attributes or metadata
Without this patch, an authenticated user can create an EC2 credential
for themself for a project they have a role on, then update the
credential to target a user and project completely unrelated to them. In
the worst case, this could be the admin user and a project the admin
user has a role assignment on. A token granted for an altered credential
like this would allow the user to masquerade as the victim user. This
patch ensures that when updating a credential, the new form of the
credential is one the acting user has access to: if the system admin
user is changing the credential, the new user ID or project ID could be
anything, but regular users may only change the credential to be one
that they still own.
Relatedly, when a user uses an application credential or a trust to
create an EC2 credential, keystone automatically adds the trust ID or
application credential ID as metadata in the EC2 access blob so that it
knows how the token can be scoped when it is used. Without this patch, a
user who has created a credential in this way can update the access blob
to remove or alter this metadata and escalate their privileges to be
fully authorized for the trustor's, application credential creator's, or
OAuth1 access token authorizor's privileges on the project. This patch
fixes the issue by simply disallowing updates to keystone-controlled
metadata in the credential.
2. Respect token roles when creating EC2 credentials
Without this patch, a trustee, an application credential user, or an
OAuth1 access token holder could create an EC2 credential or an
application credential using any roles the trustor, application
credential creator, or access token authorizor had on the project,
regardless of whether the creator had delegated only a limited subset of
roles. This was because the trust_id attribute of the EC2 access blob
was ignored, and no metadata for the application credential or access
token was recorded either. This change ensures that the access
delegation resource is recorded in the metadata of the EC2 credential
when created and passed to the token provider when used for
authentication so that the token provider can look up the correct roles
for the request.
Conflicts (six removal in e2d83ae9, pep8 fixes in e2d83ae9): keystone/api/credentials.py keystone/tests/unit/test_v3_application_credential.py keystone/tests/unit/test_v3_credential.py
Change-Id: I39d0d705839fbe31ac518ac9a82959e108cb7c1d
Closes-bug: #1872733
Closes-bug: #1872755
Closes-bug: #1872735
(cherry picked from commit 37e9907a176dad6843819b1bec4946c3aecc4548)
(cherry picked from commit 2f2736ebb267c757ad77fcf25ee0aaeefab2a09d)
(cherry picked from commit 27caafe3daa552663719954f2cd6713dd4493178)
Reviewed: https:/ /review. opendev. org/725893 /git.openstack. org/cgit/ openstack/ keystone/ commit/ ?id=206392a40ce 3da3d389e5e7ec7 21ada2737b84da
Committed: https:/
Submitter: Zuul
Branch: stable/stein
commit 206392a40ce3da3 d389e5e7ec721ad a2737b84da
Author: Colleen Murphy <email address hidden>
Date: Tue Apr 14 16:47:44 2020 -0700
Fix security issues with EC2 credentials
This change addresses several issues in the creation and use of EC2/S3
credentials with keystone tokens.
1. Disable altering credential owner attributes or metadata
Without this patch, an authenticated user can create an EC2 credential
for themself for a project they have a role on, then update the
credential to target a user and project completely unrelated to them. In
the worst case, this could be the admin user and a project the admin
user has a role assignment on. A token granted for an altered credential
like this would allow the user to masquerade as the victim user. This
patch ensures that when updating a credential, the new form of the
credential is one the acting user has access to: if the system admin
user is changing the credential, the new user ID or project ID could be
anything, but regular users may only change the credential to be one
that they still own.
Relatedly, when a user uses an application credential or a trust to
create an EC2 credential, keystone automatically adds the trust ID or
application credential ID as metadata in the EC2 access blob so that it
knows how the token can be scoped when it is used. Without this patch, a
user who has created a credential in this way can update the access blob
to remove or alter this metadata and escalate their privileges to be
fully authorized for the trustor's, application credential creator's, or
OAuth1 access token authorizor's privileges on the project. This patch
fixes the issue by simply disallowing updates to keystone-controlled
metadata in the credential.
2. Respect token roles when creating EC2 credentials
Without this patch, a trustee, an application credential user, or an
OAuth1 access token holder could create an EC2 credential or an
application credential using any roles the trustor, application
credential creator, or access token authorizor had on the project,
regardless of whether the creator had delegated only a limited subset of
roles. This was because the trust_id attribute of the EC2 access blob
was ignored, and no metadata for the application credential or access
token was recorded either. This change ensures that the access
delegation resource is recorded in the metadata of the EC2 credential
when created and passed to the token provider when used for
authentication so that the token provider can look up the correct roles
for the request.
Conflicts (six removal in e2d83ae9, pep8 fixes in e2d83ae9):
keystone/ api/credentials .py
keystone/ tests/unit/ test_v3_ application_ credential. py
keystone/ tests/unit/ test_v3_ credential. py
Change-Id: I39d0d705839fbe 31ac518ac9a8295 9e108cb7c1d 843819b1bec4946 c3aecc4548) 7ad77fcf25ee0aa eefab2a09d) 63719954f2cd671 3dd4493178)
Closes-bug: #1872733
Closes-bug: #1872755
Closes-bug: #1872735
(cherry picked from commit 37e9907a176dad6
(cherry picked from commit 2f2736ebb267c75
(cherry picked from commit 27caafe3daa5526