One tenant's admin user can modified other tenant's user’s quota info

[ling-yun]

1、Create tenant A and userA,and make userA as an admin
2、Create tenant B and userA,and make userB as an admin
3、userA login in openstack system,and create quota info “volumes:11111”
4、userB login in openstack system ,and update userA’s quota info from “volumes:11111” to “volumes:111”
5、detail test operation info see this link：http://paste.openstack.org/show/50020/

[Thierry Carrez (ttx)]

John, can you confirm this vulnerability ?

[John Griffith (john-griffith)]

Confirmed in Cinder and Nova, suspect we check is admin but ignore tenant. Have not checked other OpenStack projects.

[Thierry Carrez (ttx)]

Sounds like this is a rather significant vulnerability that should be fixed in private and trigger an embargoed advisory. Feel free to disagree with me though :)

[Jeremy Stanley (fungi)]

Yes, this does seem relatively serious. I too think an advisory is almost certainly in order, and it seems like something with a potential to be exploited in the wild if widely known.

[Andrew Laski (alaski)]

Admins are typically allowed to perform actions on other tenants, right? And if that's not desired that can be limited through policy configuration. But based on the way default policies are setup I've always considered admin to be an operator level role in which case it makes sense for the role to set quotas across tenants.

If that's not the case then it needs to be addressed in more places than just quota operations. But maybe a good start would be to change the policy defaults shipped with Nova to include "and project_id:%(project_id)s".

[Russell Bryant (russellb)]

Right, I agree with Andrew. We don't have any concept of admin beyond global admin anywhere (at least in Nova).

So, this seems like expected behavior.

[Jeremy Stanley (fungi)]

Okay, so this bug is probably invalid for Nova but valid in Cinder (does the latter have a concept of per-tenant admins)?

[Thierry Carrez (ttx)]

hmm, I'm pretty sure Nova and Cinder share the concept of cross-tenant admins.

@john-griffith: would the analysis in comment 5 also apply to Cinder ? If yes, this would not be a bug, but the default policy working as intended.

[John Griffith (john-griffith)]

Comments by Andrew and Russell have now officially completely confused me. I never knew that this was intended behavior and quite frankly I don't think it really makes much sense. I think it's likely a bug, but I also think it's project wide. The concept of some projects interpreting this one way and others a different way is about the worst thing I could possibly imagine. I'm most certainly not going to have one set of behaviors in Cinder while everyone else does something different.

@thierry
Yes, I agree with you in terms of the concept of cross-tenant admins however I always "thought" that was something you explicitly set.

[Thierry Carrez (ttx)]

At the very least this is a documentation issue, since this is clearly not obvious to everyone.
Part of it was discussed in the past @ https://bugs.launchpad.net/keystone/+bug/968696

[Thierry Carrez (ttx)]

Adding Dolph so that he can comment here

[Dolph Mathews (dolph)]

++ this is a "dupe" of https://bugs.launchpad.net/keystone/+bug/968696

This has been sort of "by [lazy] design" for a *long* time, but obviously it's a shortcoming not documented loudly enough. Having the "admin" role on any tenant/project grants you root of openstack, so to speak.

The core issue is that we're overloading the explicit role assignment in the magical case of 'admin', because we don't have any other way to express service-level authorization. So, not only does policy apply the role on the per-project (as specified), but because it's the magical "admin", it's applied globally as well.

We've had a looong running discussion about the best way to provide a long term solution; there's a pile of blueprints and mailing list threads but none have ever gained significant community support. IMO, the shortest path to a solution would be something like this:

  https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens

Which would provide explicit service-level authorization (e.g. "admin on nova" vs "admin on project X", and project-specific role assignments would no longer be applied globally.

[Thierry Carrez (ttx)]

OK, looks like that one is by design. I propose to open it and mark it a dupe.

[Jeremy Stanley (fungi)]

I think we need more input from John/Cinder before opening this... if it means there's an incorrect assumption in Cinder around this leading to a security design flaw which needs fixing there, then that detail may not yet be public knowledge?

[Thierry Carrez (ttx)]

I don't think Cinder's design relies on bad assumption around that. Cinder's usage might, though. So it might be worth attracting the attention of the OSSG on that to make sure this is properly documented everywhere.

John, thoughts ?

[John Griffith (john-griffith)]

Fortunately Cinders design doesn't make any assumptions based on this, and quite honestly doesn't behave any differently than any of the other projects at this point. Thanks to everyone for the clarification and digging a bit deeper. I'd agree that we could open and mark as a dupe as suggested by Thierry.