Reviewed:  https://review.opendev.org/725895
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=53d1ccb8a1bdbb5aa0efaacf9739b1a6f436e191
Submitter: Zuul
Branch:    stable/rocky

commit 53d1ccb8a1bdbb5aa0efaacf9739b1a6f436e191
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
    
    Conflicts due to flask reorg:
            keystone/api/_shared/EC2_S3_Resource.py
            keystone/api/credentials.py
            keystone/api/users.py
            keystone/tests/unit/test_v3_credential.py
    
    Moved the test_update_credential_non_owner unit test to
    CredentialSelfServiceTestCase since in this branch the default policies
    are not affected by #1872733.
    
    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)
    (cherry picked from commit bfba75fc3c5c8f119f74dbf31347e008824a2134)