On a not of history, we did implement this at one point and it broke
OpenStack in a ton of ways, as when someone logs out of horizon, it revoked
all tokens and long running tasks failed.

This could be improved, but it make break things again

On May 25, 2017 3:11 PM, "Lance Bragstad" <email address hidden> wrote:

> I would triage this as a Class D vulnerability. Keystone never
> implemented the logic to revoke a token based on a revoke_chain (i.e.
> revoke(A) resulting in token B being invalid because it contains token
> A's audit_id in its list of audit_ids).
>
> Fixing this bug would require keystone to add functionality for how
> tokens are revoked, which wouldn't be backportable. I think this would
> be a great feature request that would act as a hardening opportunity for
> keystone's current revocation model.
>
> I'll let other coresec folks weigh in on this.
>
> --
> You received this bug notification because you are a member of Keystone
> Core security contacts, which is subscribed to the bug report.
> Matching subscriptions: Private security bugs
> https://bugs.launchpad.net/bugs/1680911
>
> Title:
>   Revoking an unscoped token does not revoke all tokens scoped from the
>   unscoped token
>
> Status in OpenStack Identity (keystone):
>   New
> Status in OpenStack Security Advisory:
>   Incomplete
>
> Bug description:
>   This issue is being treated as a potential security risk under
>   embargo. Please do not make any public mention of embargoed (private)
>   security vulnerabilities before their coordinated publication by the
>   OpenStack Vulnerability Management Team in the form of an official
>   OpenStack Security Advisory. This includes discussion of the bug or
>   associated fixes in public forums such as mailing lists, code review
>   systems and bug trackers. Please also avoid private disclosure to
>   other individuals not already approved for access to this information,
>   and provide this same reminder to those who are made aware of the
>   issue prior to publication. All discussion should remain confined to
>   this private bug report, and any proposed fixes should be added to the
>   bug as attachments.
>
>   If you create an unscoped token (A) and you then use token A to
>   create a project-scoped token (B) you now have
>   token (A) [audit_id] = audit_id_a
>   token (A) [audit_chain_id] = [audit_id_a]
>
>   token (B) [audit_id] = audit_id_b
>   token (B) [audit_chain_id] = [audit_id_a, audit_id_b]
>
>   If you Revoke(token A) then token B should also be invalid.
>   However, this is not the case currently as there are two reasons
>   for this.
>   There is a bug that doesn't correctly catch this in revoke_models
>   because it accidently changes a list to a list in a tuple:
>   https://github.com/openstack/keystone/blob/master/keystone/
> models/revoke_model.py#L200-L201
>   This needs to have the comma removed from
>   not in (token_values['audit_chain_id'],) to not in
> (token_values['audit_chain_id'])
>
>   The second and main reason is because this functionality is never
> exposed to the user
>   and in the code it is never run here:
>   https://github.com/openstack/keystone/blob/master/keystone/
> token/provider.py#L255-L277
>   because revoke_chain=False in the parameter is never set to True in a
> call anywhere in
>   the code.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/keystone/+bug/1680911/+subscriptions
>