User cannot list their own trusts

Bug #1791973 reported by Adam Young
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Triaged
Medium
Unassigned
OpenStack Security Advisory
Won't Fix
Undecided
Unassigned

Bug Description

Heat and Admin users both commonly create trusts for other users. But any application is capable of doing this, as it requires only a scoped token to create a trust, which users pass around regularly.

If I am concerned that some other application (or unauthorized user) has created a trust with me as the trustor, I need to be able to confirm this. If I cannot perform "trust list" and see the set of trusts that have me as a trustor, I am not able to clear out spurious ones. Thus, I would not be aware of any trusts set up in my name.

Jeremy Stanley (fungi)
description: updated
Revision history for this message
Jeremy Stanley (fungi) wrote :

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

Revision history for this message
Jeremy Stanley (fungi) wrote :

While I've temporarily triaged this as a potential vulnerability under embargo, it sounds more like something we could discuss and fix in the open as a security-related improvement instead. I'm eager to get more input from Adam, the Keystone core security reviewers and other VMT members on whether they agree.

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

This is something I think can be done in the public. This is more "not enough information is given" vs. "too much" or ultimately something exploitable.

Revision history for this message
Adam Young (ayoung) wrote :

Public is fine. Just wanted it flagged as a security issue to get appropriate attention and priority. An attacker is already thinking along these lines.

Solution could be to add parameters to the API along the lines of self=true and honor that in the CLI.

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

It seems like a class D according to the VMT's taxonomy ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ). I agree this can be fixed in the open.

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

I concur, class D.

Revision history for this message
Jeremy Stanley (fungi) wrote :

Based on consensus above, I've switched the bug to public and triaged it as a class D report, tagging it as a potential hardening opportunity or security-related improvement.

information type: Private Security → Public
description: updated
Changed in ossa:
status: New → Won't Fix
tags: added: security
Changed in keystone:
status: New → Triaged
importance: Undecided → Medium
tags: added: policy
Revision history for this message
Adam Young (ayoung) wrote :

Looking at the policy check:

        # FIXME(lbragstad): Trusts have the ability to optionally include a
        # project, but until trusts deal with system scope it's not really
        # useful. For now, this should be a project only operation.
        scope_types=['project'],

It seems to me that this should be an unscoped only operation for users, where they are listing their own trusts, not scoped to a project.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.