One can request to put a volume next to any tenant's instance via InstanceLocalityFilter

[György Szombathelyi]

During working on bug #1686616, I realized that using the privileged user to find the host for an instance works for any other projects, even if the requesting user doesn't have rights to see other projects' instances.
I guess it is not a big impact, one has to know an UUID of a foreign instance, and the maximum effect is to put a volume on the host where the instance resides (if it has a cinder-volume running).
I think after the filter gets the server info via the privileged user, it must check if it has rights to access that info. If a privileged user is not configured, there's no problem.

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

If this risk relies strictly on guessing or finding a victim's instance UUID through other means, then it's a class C1 report per our taxonomy and can be triaged as a potential hardening opportunity instead. https://security.openstack.org/vmt-process.html#incident-report-taxonomy

Since C1 implies the possibility of an OSSN, I'm also subscribing the ossg-coresec team to review it.

[Sean McGinnis (sean-mcginnis)]

I don't think this is really a security concern. I don't see a possible data leak from one tenant to another. In fact, it's quite possible the chosen host could be running VMs for both the current tenant and the "spoofed" tenant.

Since this relies on knowing the UUID of the other project's instance, that further limits the concern for me. Even if brute force guessing of UUIDs was done, it would be very difficult to actually match something.

And to be clear, even if the UUID is matched, that just places the volume on that instances host. It does not make that volume available to that instance.

So I think if there is something that can be done to further harden this, that's great. But I wouldn't really consider this to be a security vulnerability.

[György Szombathelyi (gyurco)]

Yepp, it is not a big issue, just a kind of information leak. Maybe one tenant can try to DOS other tenant's VM via putting a volume next to it, and generate heavy IO.

[Tristan Cacqueray (tristan-cacqueray)]

If there are no objections, let's switch this to public and close the OSSA task.

[Jeremy Stanley (fungi)]

Consensus already seems to have been reached that this is not a vulnerability, so I'm going to open it publicly as a hardening opportunity.