User cannot list their own trusts

[Adam Young]

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)]

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.

[Jeremy Stanley (fungi)]

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.

[Morgan Fainberg (mdrnstm)]

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.

[Adam Young (ayoung)]

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.

[Tristan Cacqueray (tristan-cacqueray)]

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.

[Morgan Fainberg (mdrnstm)]

I concur, class D.

[Jeremy Stanley (fungi)]

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.

[Adam Young (ayoung)]

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.