cinder backup-list is always listing all tenants's bug for admin

Hi

I want to work on this bug. If you are not working please let me know.

Does this still need to be fixed?

Fix proposed to branch: master
Review: https://review.openstack.org/207469

Reviewed: https://review.openstack.org/207469
Committed: https://git.openstack.org/cgit/openstack/python-cinderclient/commit/?id=8cc3ee2782260498cfb3d36f5469e7086b4fe6f5
Submitter: Jenkins
Branch: master

commit 8cc3ee2782260498cfb3d36f5469e7086b4fe6f5
Author: Yuriy Nesenenko <email address hidden>
Date: Thu Jul 30 16:57:39 2015 +0300

    Add support '--all-tenants' for cinder backup-list

    Also added support '--name', '--status', '--volume-id' arguments
    for cinder backup-list.

    DocImpact
    Closes-Bug: #1422046
    Depends On: I73f6377c7d6fd92d0464d13f9c8dd6682fef78e3
    Change-Id: I5f2ab6370a8333a9ee498c6158037b0433f36a23

ospurge is afected by this bug, the risk is deleting backup volumes of the entire production instead of a unique tenant:
https://bugs.launchpad.net/ospurge/+bug/1498533

There is a potential risk of deleting all volume backups of a production system with ospurge and python-cinderclient < 1.4.0

Fix proposed to branch: master
Review: https://review.openstack.org/227911

Reviewed: https://review.openstack.org/227911
Committed: https://git.openstack.org/cgit/stackforge/ospurge/commit/?id=b97992d5099ce8aa9371a5b78461d11faacbea5a
Submitter: Jenkins
Branch: master

commit b97992d5099ce8aa9371a5b78461d11faacbea5a
Author: Yves-Gwenael Bourhis <email address hidden>
Date: Fri Sep 25 17:23:06 2015 +0200

    Do not list cinder backups as admin with cinderclient<1.4.0

    Due to the following bug:
    https://bugs.launchpad.net/python-cinderclient/+bug/1422046
    We do not attempt to list cinder backups as admin if cinderclient's version is
    lower than 1.4.0

    Change-Id: I570971391cff80e1d6a484c330e80f901f5210b3
    Closes-Bug: #1422046

Horizon is affected because as long as cinderclient <1.4.0, if the user is logged in with admin permissions, the user lists all cinderbackup resources instead of the ones of his own tenant, with the reisk of tampering with ressources from another tenant/user.

This can be a security issue, because openstack admins may not be aware that they are seeing other users' cinder backup ressources and can delete them.

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.

It looks like bug 1514396 has been opened for the same issue in the V1 API.

While I agree there is a non-negligible risk presented by this behavior, I don't see how a malicious actor could use this flaw to their advantage. As such, it doesn't seem like something for which the OpenStack Vulnerability Management Team would issue an official security advisory.

Indeed, I agree that there is no risk for a "malicious actor" to use this flow.
However there is a confirmed risk that an openstack admin can accidentally delete backups which he should not delete (and it DID happen, sadly...), when the admin is asked to launch scripts (ospurge) used to delete resources of customers who want to remove all their data...

Sounds like we're agreed that this report concerns a serious bug with security implications (insofar as any means of accidentally destroying your environment is), but is not an exploitable vulnerability, does not need a CVE assignment requested by the VMT and won't lead to any official security advisory publication.

Sure, I completely agree with that.

There should be a way to differentiate security issues in terms of "vulnerability" (which is not the case here) and security issues in terms of "risks of destroying data" due to a bug (which is the case here).

Correct, we consider that latter case a "security hardening opportunity" and I'm triaging this report as one now (class D in our taxonomy https://security.openstack.org/vmt-process.html#incident-report-taxonomy ). Depending on severity and available time from editors in the Security Team, these sorts of issues sometimes get an OpenStack Security Note published (OSSN rather than OSSA).

Thanks a lot Jeremy for the the link and clarification.

This issue was fixed in the openstack/python-cinderclient 1.4.0 release.

Closing the horizon portion of this bug since it is now
outside of the support window.