Synchronise 2024.1 with upstream - #46
Open
github-actions[bot] wants to merge 11 commits into
Open
Conversation
Delegated tokens (trusts, application credentials, OAuth1 access tokens)
are scoped to a single project at delegation time. This must be enforced
thoroughly while granting the API access to Keystone resources that
might be also bound to a single project. Without this it is possible to
gain different access (using trust to see application credentials for a
different project, reuse the MFA seed, etc).
* Credentials CRUD (/v3/credentials)
All five CRUD operations verified ownership via user_id but did not bind
credential.project_id to the delegating token's project scope.
Fix: _check_credential_project_scope() - no-op for non-delegated tokens,
raises ForbiddenAction on project mismatch. For list, out-of-scope
credentials are silently filtered.
Credentials with project_id=None (TOTP/MFA bindings) are treated as
out-of-scope for any delegated token: they are user-level secrets with no
project anchor, and a delegated token should never be able to enumerate,
read, or mutate them - doing so would allow a stolen delegation token to
exfiltrate or destroy a user's MFA binding.
* OS-EC2 credential CRUD (/v3/users/{id}/credentials/OS-EC2)
POST accepted any tenant_id from a delegated token. GET and DELETE had
no delegation check at all.
Fix: _check_delegation_for_ec2() enforces the project boundary;
list silently filters.
Additionally, pre-existing OAuth1 access-token-backed EC2 credentials
with a mismatched project_id could be used at auth-time (POST /v3/ec2tokens)
to obtain a cross-project token. Added a check in EC2_S3_Resource.py that
cred_data['project_id'] matches access_token['project_id'] before issuing
the token. The trust branch does not need this check - the token provider
uses the trust's project regardless of the credential's project_id.
* OS-OAUTH1 access token management (/v3/users/{id}/OS-OAUTH1/access_tokens)
GET and DELETE had no delegation check. List blocked trust/OAuth but not
app-cred tokens.
Fix: _block_delegated_token() raises Forbidden for any delegation type
on list, get, and delete.
* Application credential management (/v3/users/{id}/application_credentials)
Trust-scoped and OAuth1 tokens had no guard on the application credential
and access rule management APIs. An impersonating trust could LIST, CREATE,
or DELETE application credentials, creating a persistent backdoor that
outlives the trust's own expiry. App credential tokens are intentionally
excluded - the unrestricted/restricted distinction is handled separately by
_check_unrestricted_application_credential.
Fix: _block_delegated_token_app_creds() raises Forbidden for trust-scoped
and OAuth1 tokens on all six app credential and access rule endpoints.
Only for unmaintained/2024.1: Make pep8 job non-voting, it is unclear
how the checks are different compared to stable branches and why, but it
doesn't seem reasonable to hold up this stack of security fixes due to
it.
Closes-Bug: #2150089
Related-Bug: #2149789
Related-Bug: #2149775
Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Change-Id: Iaaa0ec713a0a5e062acc3209d6010982899d8f6f
Signed-off-by: Grzegorz Grasza <xek@redhat.com>
Signed-off-by: Artem Goncharov <artem.goncharov@gmail.com>
(cherry picked from commit 16582e5192be354e26ebef4badca1213ddc4dc07)
(cherry picked from commit 1b27d28)
When authenticating by application credential ID, the caller can supply a 'user' field in the payload. AppCredInfo conditionally set the user from the credential owner only when no user field was present. If present, BaseUserInfo resolved the caller-supplied user and attributed the resulting token to that user instead of the credential owner. Fix: always set auth_payload['user'] from the credential's stored user_id, ignoring any caller-supplied value. Closes-Bug: #2148477 Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Boris Bobrov <b.bobrov@sap.com> Change-Id: I2fe6089886eebf3775930451b87771e40b5e179e Signed-off-by: Grzegorz Grasza <xek@redhat.com> Signed-off-by: Artem Goncharov <artem.goncharov@gmail.com> (cherry picked from commit 6cd25fecdab8b9261e916ee10f3dba5aeb0c1984) (cherry picked from commit 90fe79c)
Previously only restricted application credentials were blocked, and only for trust create and delete. This change blocks all application credentials (restricted and unrestricted alike) from all trust operations: list, get, create, delete, list-roles, and get-role. The 'unrestricted' flag governs credential management, not trust management. Closes-Bug: #2148477 Related-Bug: #2149789 Related-Bug: #2150089 Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Boris Bobrov <b.bobrov@sap.com> Change-Id: I750156df18a1d6293ce99c42eb524575fcf16ea3 Signed-off-by: Grzegorz Grasza <xek@redhat.com> Signed-off-by: Artem Goncharov <artem.goncharov@gmail.com> (cherry picked from commit 3c2043ab003cb4b8aa34502fe9a5a69b0a6a6e54) (cherry picked from commit 50c30d1)
When a federated token is rescoped via POST /v3/auth/tokens the
handle_scoped_token function returned response_data without an expires_at
value. Because issue_token falls back to default_expire_time when
expires_at is None, each rescope issued a fresh full-TTL token instead of
inheriting the remaining lifetime of the original token.
A user with a federated token could extend their session indefinitely by
rescoping repeatedly before expiry, bypassing operator-configured TTL
policies and IdP-level account revocation.
Fix: propagate token.expires_at from handle_scoped_token so that
issue_token uses the original token's expiry rather than resetting to
the default. The non-federated path in token.py already did this via
response_data.setdefault('expires_at', token.expires_at).
Closes-Bug: #2150379
Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Artem Goncharov <artem.goncharov@gmail.com>
Change-Id: I0bbb8520e12c52edd01fb47c873f0227819706f5
Signed-off-by: Grzegorz Grasza <xek@redhat.com>
(cherry picked from commit 75a4a0c354c7f568b28dd85182dc729553fb3a33)
(cherry picked from commit 7846c23)
…42999) The RBAC enforcer unconditionally merged the raw JSON request body into the policy enforcement dictionary after trusted target data had been set from the database. An attacker could include a "target" key in the JSON body to overwrite database-sourced RBAC target attributes, causing all %(target.*)s policy substitutions to evaluate against attacker-controlled values. This affected 88 endpoint/method combinations across all Keystone API resources. The fix namespaces user-controlled JSON body data under a "request_body" key in the policy dict, making it structurally impossible for request body fields to collide with internal keys like "target" or view_args. The only in-tree policy rule that depended on the old JSON body merge behavior was identity:create_trust, which referenced %(trust.trustor_user_id)s from the request body at the top level of the policy dict. This is updated to use target_attr and the %(target.trust.trustor_user_id)s substitution, consistent with all other trust policy rules. Additionally, query-string filter values had the same structural issue: _extract_filter_values() results were merged at the top level, meaning a filter key matching a view_arg key (e.g. user_id on /v3/users/{user_id}/... endpoints using ADMIN_OR_SYSTEM_READER_OR_OWNER) could be overwritten by an attacker-controlled ?user_id= query param, bypassing ownership checks. Filter values are now namespaced under "filter_attr". No in-tree policy rule references filter values via %(key)s substitutions, so this is backwards-compatible for upstream deployments. Closes-Bug: #2148398 Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Boris Bobrov <b.bobrov@sap.com> Co-authored-by: Artem Goncharov <artem.goncharov@gmail.com> Change-Id: I295d1ac27faad05a680bb2b3fac8cfa27fa1c4bd Signed-off-by: Grzegorz Grasza <xek@redhat.com> (cherry picked from commit 22b51f5d5d86350d3fbc66697e4097bacf2a8ce9) (cherry picked from commit 2743acb)
… unmaintained/2024.1
…26-42998)" into unmaintained/2024.1
…6-43000)" into unmaintained/2024.1
…44394)" into unmaintained/2024.1
…E-2026-42999)" into unmaintained/2024.1
github-actions
Bot
added
automated
Change-Id: If92da9eff16b94d8ac25c066ee59d160d3b20e2d
priteau
force-pushed
the
upstream/2024.1-2026-08-31
branch
from
August 31, 2026 11:58
d8e2b4a to
92fa191
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains a snapshot of 2024.1 from upstream unmaintained/2024.1.