Debian Patches

Status for keystone/2:22.0.2-0+deb12u3

Patch Description Author Forwarded Bugs Origin Last update
fixes-keystone-default-catalog.patch Fix default keystone catalog Fix default catalog so that it matches the region name which is set by
default by debconf in all of the Openstack Debian packages.

diff --git a/etc/default_catalog.templates b/etc/default_catalog.templates
index e885b52..936be8b 100644		 Thomas Goirand <zigo@debian.org> no 2016-03-03
install-missing-files.patch install missing files Thomas Goirand <zigo@debian.org> not-needed 2019-08-18
Consistent_and_Secure_RBAC_Phase_1.patch Consistent and Secure RBAC (Phase 1)
This patch updates system-scoped policies to also accept project-admin
tokens so that operators can continue to use the "admin" role to access
system level APIs.

The protection test job is marked non-voting since tempest does not yet
expect these policy changes. A follow-up patch will make it voting
again after the test changes have merged into tempest.

[1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-1

(cherry picked from commit f2f1a5c38847ddc5aa28eec9722885d9c64c6e7b)
(cherry picked from commit 991662c666b6dcb410a622c9ec32e18a094757b2)		 Douglas Mendizábal <dmendiza@redhat.com> no 2023-12-05
Fix_policies_for_groups.patch Fix policies for groups This patch fixes a couple of broken policies in the groups resource.

diff --git a/keystone/common/policies/group.py b/keystone/common/policies/group.py
index 024ee65..8c8293c 100644		 Douglas Mendizábal <dmendiza@redhat.com> no upstream, https://review.opendev.org/c/openstack/keystone/+/906892 2025-10-30
Allow_admin_to_access_tokens_and_credentials.patch Allow admin to access tokens and credentials
This patch modifies a few policies to allow users with the "admin" role
to access /v3/auth/tokens and /v3/credentials. These policies were
missed when we implemented Phase 1 of Secure RBAC.

(cherry picked from commit b31007e1b2ecbea5e1268d3e28d6230d0f5d09b2)
(cherry picked from commit 0dcc423a2621943ab9188cff3edb9bc488339fe0)
(cherry picked from commit 570c19e91bc3212f748221bdab5f2976f479fa13)		 Douglas Mendizábal <dmendiza@redhat.com> no 2024-03-27
Dont_enforce_when_HTTP_GET_on_s3tokens_and_ec2tokens.patch Dont enforce when HTTP GET on s3tokens and ec2tokens When calling the s3tokens or ec2tokens API with a
HTTP GET we should get a 405 Method Not Allowed but
we get a 500 Internal Server Error because we enforce
that method.

diff --git a/keystone/api/_shared/EC2_S3_Resource.py b/keystone/api/_shared/EC2_S3_Resource.py
index ff94286..7b2fc21 100644		 Tobias Urdin <tobias.urdin@binero.se> yes upstream upstream, https://review.opendev.org/c/openstack/keystone/+/908760 2025-10-30
keystone-bug-2119646-stable-2024.1.patch Add service user authentication to ec2 and s3 endpoints
Add a policy to enforce authentication with a user in the service
group. This maintains AWS compatibility with the added security
layer.

(cherry picked from commit 69d299eab04a1e1bab25eb89e0fdf7f0106b8ee5)		 Grzegorz Grasza <xek@redhat.com> no 2025-09-19
CVE-2026-33551~OSSA-2026-005_Prevent_unauthorized_EC2_credential_creation_and_deletion.patch CVE-2026-33551 / OSSA-2026-005: Prevent unauthorized EC2 credential creation and deletion A restricted application credential could be used to create EC2
credentials granting full user access to S3, bypassing the role
restriction. Add the same _check_unrestricted_application_credential
guard that already protects application credential create/delete
endpoints.
.
Additionally, tighten the ec2_create_credential and ec2_delete_credential
policies to require at least member role, as these are write operations
that should not be accessible to reader-role users regardless of whether
they are using an application credential.

===================================================================		 Grzegorz Grasza <xek@redhat.com> yes debian upstream upstream, https://review.opendev.org/c/openstack/keystone/+/983597 2026-04-10
CVE-2026-40683-OSSA-2026-007-fix_ldap_enabled_setting_not_interpreted_as_boolean.patch CVE-2026-40683 / OSSA-2026-007: fix ldap 'enabled' setting not interpreted as boolean interpretation of the ldap enabled attribute as boolean
is only done if enabled_invert setting is set to true.
.
Conflicts:
keystone/identity/backends/ldap/core.py
.
NOTE(elod.illes): conflict is due to Blakify patch [1] that was added
in 2024.2 Dalmatian release.
.
[1] I832ec4c152fa58fb0088d9f880add86a20ec95fc

===================================================================		 Benedikt Trefzer <benedikt.trefzer@cirrax.com> yes debian upstream upstream, https://review.opendev.org/c/openstack/keystone/+/984587 2026-04-15
0001-Add-tests-for-restricted-app-cred-guard.patch [PATCH 1/5] 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/5] 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-cred-tokens-from-authorizing-OAuth1-reques.patch [PATCH 3/5] 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
0004-Enforce-app-cred-project-boundary-on-EC2-credential-.patch [PATCH 4/5] 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)
(cherry picked from commit d9e18a37888cabdea919c58b24f630fd722aa8b0)		 Grzegorz Grasza <xek@redhat.com> no 2026-04-22
CVE-2026-43001-keystone-backport-stable-2025.1.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.

===================================================================		 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