Debian Patches

Status for keystone/2:29.0.1-2

Patch Description Author Forwarded Bugs Origin Last update
install-missing-files.patch install missing files Thomas Goirand <zigo@debian.org> not-needed 2019-08-18
do-not-set-chartset-in-flask-responce.patch Do not set charset in flask responce
===================================================================		 Thomas Goirand <zigo@debian.org> no 2024-01-22
set-deprecation-warnings-to-ignore.patch Set deprecation warnings to ignore Otherwise, Keystone FTBFS in Unstable. Thomas Goirand <zigo@debian.org> no 2025-03-13
0001-Add-tests-for-restricted-app-cred-guard.patch [PATCH 1/6] Add tests for restricted app cred guard
Verify that the _check_unrestricted_application_credential guard on
the OS-EC2 credential create endpoint blocks restricted application
credentials from creating EC2 credentials, while still allowing
unrestricted application credentials to do so.

(cherry picked from commit c87ce6ed435f01431343d6b2bb6697a640514d27)		 Boris Bobrov <b.bobrov@sap.com> no 2026-04-07
0002-Block-restricted-app-creds-from-creating-EC2-credent.patch [PATCH 2/6] Block restricted app creds from creating EC2 credentials via /credentials

The POST /v3/credentials endpoint accepted EC2 credential creation
from restricted application credential tokens, bypassing the guard
on the dedicated OS-EC2 endpoint. Add the same unrestricted
application credential check to the generic credentials API for
EC2-type credentials, and update the existing test to use an
unrestricted application credential.

(cherry picked from commit d6a3dc511057d6ac25bd2d75776a4233c5608684)		 Boris Bobrov <b.bobrov@sap.com> no 2026-04-07
0003-Block-app-credential-token-rescoping.patch [PATCH 3/6] Block app credential token rescoping
Application credential tokens could be rescoped to system scope
via token-from-token auth, bypassing the intended scope binding.
The check only blocked project and domain scope but not system,
allowing escalation to full system-admin privileges.

Check for any requested scope rather than enumerating individual
scope types.

(cherry picked from commit 836f6b98648ee713c368a803eabe01a66f161372)		 Boris Bobrov <b.bobrov@sap.com> no 2026-03-19
0004-Include-system-scope-in-rescope-guard.patch [PATCH 4/6] Include system scope in rescope guard
The allow_rescope_scoped_token=False configuration option is
meant to prevent any scoped token from being used to create
another token. The check only covered project-scoped and
domain-scoped tokens but not system-scoped tokens, allowing
a system-scoped token to be rescoped despite the setting.

(cherry picked from commit bcc8e819a8611e2f5a8bc1a61cfa792269106c1a)		 Boris Bobrov <b.bobrov@sap.com> no 2026-03-25
0005-Enforce-app-cred-project-boundary-on-EC2-credential-.patch [PATCH 5/6] Enforce app cred project boundary on EC2 credential paths
POST /v3/credentials did not validate that the caller-supplied
project_id for an EC2-type credential matched the project of the
authenticating application credential. This allowed an attacker
holding an unrestricted application credential for project A to
create an EC2 credential targeting project B; a subsequent
/v3/ec2tokens exchange would then issue a Keystone token scoped to
project B while still carrying the original app_cred_id, enabling
cross-project lateral movement within the credential owner's role
footprint.

Two fixes:

1. credentials.py: after extracting app_cred_id from the token,
check that credential['project_id'] == app_cred['project_id']
for EC2-type credentials and raise ForbiddenAction otherwise.

2. EC2_S3_Resource.py: in handle_authenticate(), assert that the
stored EC2 credential project_id matches the application
credential's project before issuing the token.

This issue is orthogonal to CVE-2026-33551 (LP#2142138 / Gerrit
983655), which blocks restricted application credentials from
creating EC2 credentials at all. The project-boundary check is
absent regardless of the restricted flag and requires separate
treatment.

(cherry picked from commit b6fd80996b882890a51f3e2aab41d952d7ff68ae)		 Grzegorz Grasza <xek@redhat.com> no 2026-04-22
0006-Block-app-cred-tokens-from-authorizing-OAuth1-reques.patch [PATCH 6/6] Block app cred tokens from authorizing OAuth1 requests
The OAuth1 authorize endpoint checked is_delegated_auth to block
trust-scoped and OAuth-scoped tokens from authorizing request
tokens, but application credential tokens were not covered by
this check. A restricted application credential could authorize
a request token with any role the user actually holds, producing
an access token that yields an unrestricted Keystone token with
roles beyond the application credential's restricted set.

Add an explicit check for application credential tokens on the
OAuth1 authorize endpoint, consistent with how trust-scoped and
OAuth-scoped tokens are already blocked.

(cherry picked from commit 29246c5fd8d1dafbe6cc8cec4c57faf5590cd44e)		 Boris Bobrov <b.bobrov@sap.com> no 2026-04-07
CVE-2026-43001-2026.1.v4.patch [PATCH 1/5] Enforce delegation project boundary for delegated tokens 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.
.

diff --git a/keystone/api/_shared/EC2_S3_Resource.py b/keystone/api/_shared/EC2_S3_Resource.py
index 80f1bc918..5deacd0a2 100644		 Grzegorz Grasza <xek@redhat.com> yes debian upstream upstream, https://bugs.launchpad.net/keystone/+bug/2150089 2026-05-26

All known versions for source package 'keystone'

Links