Debian Patches

Status for keystone/2:22.0.2-0+deb12u4

Patch Description Author Forwarded Bugs Origin Last update
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
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
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
CVE-2026-80182_CVE-2026-80184_1_Block_app_credential_token_rescoping.patch 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.

===================================================================		 Boris Bobrov <b.bobrov@sap.com> yes upstream upstream, https://review.opendev.org/c/openstack/keystone/+/987626 2026-08-11
CVE-2026-80182_CVE-2026-80184_2_Ban_ec2credential_tokens_from_Keystone_API.patch Ban ec2credential tokens from Keystone API
EC2 credentials are supported by Keystone only to allow Swift to
implement S3 protocol while using Keystone identities. There are no real
reasons for ec2credential fernet tokens (after authenticating) being
accepted by the Keystone itself. There are many barriers where
Keystone explicitly checks and bans such credentials to prevent
rescoping or accessing resources belonging to other projects. There
have been multiple security issues due to missing guards. Instead of
those individual barriers, simply bar such tokens from any Keystone
operation except validating the token (which Swift needs to do) and
re-authenticating (renewing the token). The latter is questionable on
its own, but is kept for now.

Solve the problem by simply rejecting the ec2credential issued token
in the auth middleware which runs before any authenticated request.
The /auth/tokens are unauthenticated and as such are not affected.		 Artem Goncharov <artem.goncharov@gmail.com> no 2026-07-15
CVE-2026-80182_CVE-2026-80184_3_auth_encode_ec2credential_and_oauth2_credential_in_the_method_bitmask.patch auth: encode ec2credential and oauth2_credential in the method bitmask
convert_method_list_to_integer() builds its map from CONF.auth.methods,
so a method name absent from that list is silently dropped and the
result is 0, which convert_integer_to_method_list() turns back into
an empty list.

'ec2credential' (keystone.api._shared.EC2_S3_Resource) and
'oauth2_credential' (keystone.api.os_oauth2) are written into
token.methods by endpoints that are not auth plugins, so they cannot
be listed in CONF.auth.methods: load_auth_methods() would look for a
keystone.auth.<name> entry point that does not exist, and the name
would become client-requestable on POST /v3/auth/tokens. Neither has
ever survived the fernet round-trip.

Master already ships the EC2 API ban (910ebab06) which rejects
tokens with 'ec2credential' in token.methods. Without this round-trip
fix that check never sees the method on a fernet token, so the ban
is a no-op for issued tokens.

Reserve fixed high bits for both so they round-trip. High and fixed
means they never collide with the sequential indexes and adding one
never shifts an existing index, so tokens in circulation stay
decodable.

This does not fix tokens already issued: they carry the integer 0
and still decode to an empty list.		 Benjamin Pinchon <benjamin.pinchon@corp.ovh.com> no 2026-08-25
CVE-2026-80182_CVE-2026-80184_4_trusts_oauth1_app-creds_reject_delegated_tokens_across_all_endpoints.patch trusts, oauth1, app-creds: reject delegated tokens across all endpoints
_check_application_credential() in trusts.py only recognized
'application_credential' in token.methods, so OAuth1 access-token-scoped
and ec2credential-derived tokens were never blocked from creating,
listing, reading, or deleting trusts -- unlike application_credential,
which has had this restriction since LP#2148477.

Two more endpoints that mint a new persistent grant had the same gap:

- users.py's _block_delegated_token_app_creds (guarding application
credential and access-rule CRUD) only checked trust_id/access_token_id,
so ec2credential-scoped tokens could create, list, read, and delete
application credentials.
- os_oauth1.py's AuthorizeResource.put (PUT /v3/OS-OAUTH1/authorize) only
checked is_delegated_auth (trust/oauth1) and application_credential, so
an ec2credential-scoped token could authorize OAuth1 request tokens.

All three are extended to the same primary-auth-method allowlist used in
credentials.py, users.py, and token.py: any token whose methods aren't
entirely primary auth methods is rejected outright. Trust-scoped tokens
are deliberately not blocked from trust operations on trust_id alone --
that's the trust redelegation feature working as designed (a trustee
creating a further, narrower trust from one they were delegated) and
trustee self-service reads of their own trusts. A trust-scoped token
whose underlying method is itself delegated (an EC2 credential's blob
can embed a trust_id, see keystone.api.credentials._assign_unique_id) is
still caught by the method check regardless of trust scoping.
application_credential keeps its existing, documented opt-in escape
hatch for trust management
(allow_insecure_application_credential_trust_escalation) and its
unrestricted/restricted distinction for creating further application
credentials (_check_unrestricted_application_credential); OAuth1 and EC2
credentials have no such use case and are blocked unconditionally
everywhere.

This also closes off the underlying role-escalation path in trust
assignments, not the requesting token's own scoped roles, so a
narrowly-scoped oauth1/ec2 token could previously delegate roles it was
never itself authorized for. Blocking those token types from trust
creation removes the path to that gap without needing to touch the
validation itself.

Neither the app-cred nor the OAuth1-authorize gap is reachable on
current master, where a separate middleware change globally rejects any
caller token with 'ec2credential' in its methods before Flask routing --
but that change is not backported to stable branches, so both gaps are
live there. Fixed at the source regardless, so the guard doesn't depend
on an unrelated middleware check remaining in place.

An empty token.methods list (e.g. an ec2credential-derived token that
lost its methods on a fernet cache-miss round-trip -- ec2credential has
no bit in the method bitmask) is also treated as delegated at all three
call sites: _PRIMARY_AUTH_METHODS.issuperset([]) is True, so without this
an empty list would otherwise be accepted as 'all primary'.

Consolidated the three independent _PRIMARY_AUTH_METHODS copies (this
patch, LP#2158538, LP#2159643) into keystone.api._shared.delegation,
per gtema's review comment #16 -- now that all three land together the
NameError-avoidance reason for keeping them separate no longer applies.
Also replaced the hardcoded method list with an operator-extensible one
([auth] additional_primary_auth_methods): a hardcoded allowlist blocks
any third-party auth plugin (e.g. a site-specific SSO integration) from
reauthenticating/managing its own trusts, app-creds, and OAuth1 tokens,
since it can never appear in a list only keystone maintainers can edit.

(cherry picked from commit c8872fabde992542b304895f90d5ac1651e87e24)		 Grzegorz Grasza <xek@redhat.com> no 2026-07-23
CVE-2026-80182_CVE-2026-80184_5_auth_reject_delegated_tokens_from_token-method_reauthentication.patch auth: reject delegated tokens from token-method reauthentication
token_authenticate() unconditionally blocks trust-scoped and
OAuth1-scoped tokens from creating another token via the token
method, but application_credential tokens were only blocked from
requesting an explicit scope -- an omitted scope fell through to
the user's default-project scoping, letting an app-cred token
bound to project A come back scoped to the user's default project
B. ec2credential tokens matched no check at all, so they could
rescope via an explicit scope to any project the underlying user
has a role on, not just a default-project fallback.

Both are the same root cause: application credentials and EC2
credentials are deliberately narrow, single-project grants, and the
"token" method's rescoping logic never accounted for that, treating
them like a normal user session that's free to move between any of
its own role assignments.

Block application_credential tokens from this path entirely,
matching trust/OAuth1, using the same shared
keystone.api._shared.delegation classification introduced by
LP#2153453: any token whose methods aren't entirely primary auth
methods (built-in, or operator-registered via
[auth] additional_primary_auth_methods) is rejected outright,
including ec2credential and any future delegated method. An empty
token.methods list (e.g. an ec2credential-derived token that lost its
methods on a fernet cache-miss round-trip) is also treated as
delegated, since issuperset([]) is True and would otherwise be
accepted as 'all primary'.

(cherry picked from commit f2761bb60a7e48510ab22c4865d9601345422ce9)		 Grzegorz Grasza <xek@redhat.com> no 2026-08-24
CVE-2026-80182_CVE-2026-80184_6_fix-unit-tests.patch Fix unit tests Thomas Goirand <zigo@debian.org> no 2026-08-26
CVE-2026-80183_Prevent_unauthorized_project-scoped_assignment_list.patch Prevent unauthorized project-scoped assignment list
Any user holding `role:reader` on any project could list all role
assignments under any domain by passing a domain ID as
`scope.project.id` to `GET /v3/role_assignments?include_subtree`.
Domain projects store `domain_id=null`, which matched the `null`
`domain_id` of any project-scoped token in the oslo.policy string
comparison, bypassing the domain-reader restriction. An explicit `not
None:%(target.domain_id)s` guard has been added to the affected policy
rules.

(cherry picked from commit eb27f4e309708746a8e7a5f0ad7e9a510e47ff0b)		 Artem Goncharov <artem.goncharov@gmail.com> no 2026-08-04

All known versions for source package 'keystone'

Links