Debian Patches

Status for keystone/2:29.0.2-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
CVE-2026-80182_CVE-2026-80184_1_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.
.
Add a config option, [auth] ban_ec2credential_tokens, default True, so
deployments with an undocumented dependency on using EC2-derived
tokens directly against the API can opt out instead of being broken
outright. Also add a release note, since this changes existing,
documented API behavior for anyone relying on it.

diff --git a/keystone/conf/auth.py b/keystone/conf/auth.py
index 0de24b9..59d7121 100644		 Artem Goncharov <artem.goncharov@gmail.com> no debian upstream, https://review.opendev.org/c/openstack/keystone/+/1002082 2026-08-26
CVE-2026-80182_CVE-2026-80184_2_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
creation: trust role validation checks the trustor's full role
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.

diff --git a/keystone/api/_shared/delegation.py b/keystone/api/_shared/delegation.py
new file mode 100644
index 0000000..5812ec6		 Grzegorz Grasza <xek@redhat.com> no debian upstream, https://review.opendev.org/c/openstack/keystone/+/1002303 2026-08-27
CVE-2026-80182_CVE-2026-80184_3_lp-2158538-2026.1.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, and add a primary-auth-method allowlist
fallback so ec2credential, and any future delegated method, is
rejected the same way by default.
.

diff --git a/keystone/auth/plugins/token.py b/keystone/auth/plugins/token.py
index 428d4abd9..3ecb8f9b3 100644		 Grzegorz Grasza <xek@redhat.com> yes debian upstream https://review.opendev.org/c/openstack/keystone/+/1002304 2026-08-27
CVE-2026-80182_CVE-2026-80184_4_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.

diff --git a/keystone/auth/plugins/core.py b/keystone/auth/plugins/core.py
index 475c9cb..f5d133c 100644		 Benjamin Pinchon <benjamin.pinchon@corp.ovh.com> no debian upstream, https://review.opendev.org/c/openstack/keystone/+/1002303 2026-08-27
CVE-2026-80182_CVE-2026-80184_5_fix-unit-test.patch Fix unit test Thomas Goirand <zigo@debian.org> no debian 2026-08-26
CVE-2026-80183_Prevent_unauthorized_project-scoped_assignment_list.patch CVE-2026-80183 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.

diff --git a/keystone/common/policies/role_assignment.py b/keystone/common/policies/role_assignment.py
index 76c9182..10137e5 100644		 Artem Goncharov <artem.goncharov@gmail.com> yes debian upstream upstream, https://review.opendev.org/c/openstack/keystone/+/1002412 2026-08-27

All known versions for source package 'keystone'

Links