Bug Description

It's well known that Glance does not perform any check on tenants.  This has been a behavior we kept as-is to avoid increasing requests needed in the image management process, however, after some tests, I think this behavior can be a security issue. 

Scenario:
- Create an image using user1
- Pick tenant's id of user2 and add it as a member of the image user1 just created
- Use user2 to list images.  This will list the image user1 created. 

I think this is an issue because it allows user from other tenants to sneak images with a backdoor to other tenants. 

CVE References

I assume this behavior has been exploitable back at least as far as essex?  When you say well-known, is the choice not to check tenant membership on these operations publically documented (not just buried in the source code or hinted at in mailing list archives)?  Are there scenarios where this could reasonably compromise tenant security or is it simply a means of bypassing resource limits/restrictions?  I'm basically trying to work out whether this warrants an advisory, and if so what risks it presents to whom. 

Following an E-mail discussion with Flavio and Kurt from Red Hat, I'm making this bug public to expedite broader discussion and mitigation.  Also, per Kurt, this affects at least Folsom, Grizzly and presumably Havana (no word yet on whether it extends back as far as Essex). 

The trick here is that "fixing" this would significantly alter the behavior of Glance by preventing something that was always supported so far (and could be used for good reasons)... We could document the risk and address it in future API releases, but that would not address the "vulnerability".  Thoughts ? 

We however could not *fix* it without breaking backwards compatibility in v1.  Hence, we held off on memberships in v2.0, and then only added them in v2.1 when we were sure that we could prevent this kind of griefing/spamming. 

In v2.1+, when you add a tenant id as a member to an image, the membership starts out in the "pending" state. " Pending" memberships can be viewed by users in that tenant by querying specifically for "membership-status=pending", however, they must be "accepted" before they show up in the default listing.  This puts in place a two step solution that IMO generally resolves the security issue. 

In addition, it is possible for deployers to limit image sharing to specific roles, in case more control is required. 

So I'm not sure if this bug is "invalid", "fix released", or "wontfix" at this point. 

It is true that this issue was fixed in v2.1 but it still exists in previous versions of the API.  I agree on the fact that this behavior has been well understood for some time but I'm not sure people is aware of this vulnerability, though. 

I agree with Thierry's idea of documenting the vulnerability somewhere without changing the way Glance works.  I also prefer to keep Glance the way it is today, if we all agree that documenting this is enough to close this bug. 

### Summary ###
Glance allows images to be shared between projects.  In certain API versions, images can be shared without the consumer project's approval.  This allows potentially malicious images to show up in a project's image list. 

### Discussion ###
Since the OpenStack Diablo release, Glance allows images to be shared between projects.  To share an image, the producer of the image adds the consumer project as a member of the image.  When using the Image Service API v2.0 and earlier, the image producer is able to share an image with a consumer project without their approval.  This results in the shared image showing up in the image list for the consumer project.  This can mislead users with roles in the consumer project into running a potentially malicious image. 

The Image Service API v2.1 makes image sharing a two-step process.  An image producer must add a consumer as a member of the image, and the consumer must accept the shared image before it shows up in their image list.  This additional approval process allows a consumer to control what images show up in their image list, thus preventing potentially malicious images being used without the consumers knowledge

### Recommended Actions ###
In the OpenStack Diablo, Essex, and Folsom releases, Glance supports image sharing using the Image Service API v2.0 or earlier.  There is no way to require approval of a shared image by consumer projects.  Users should be cautioned to be careful when using images from their image list, as they may be using an image that was shared with them without their knowledge. 

In the OpenStack Grizzly and Havana releases, Glance supports the Image Service API v2.1 or later.  Support is still provided for Image Service API v1, which allows image sharing between projects without consumer project approval.  It is recommended to disable v1 of the Image Service API if possible.  This can be done by setting the following directive in the glance-api.conf configuration file:

This looks very good.  I do, however, have one correction I would like to submit.  In v2.0 of the images api, we simply did not include image sharing--so the vulnerability does not exist there.  It is only part of the v1 series. 

### Summary ###
Glance allows images to be shared between projects.  In certain API versions, images can be shared without the consumer project's approval.  This allows potentially malicious images to show up in a project's image list. 

### Discussion ###
Since the OpenStack Diablo release, Glance allows images to be shared between projects.  To share an image, the producer of the image adds the consumer project as a member of the image.  When using the Image Service API v1, the image producer is able to share an image with a consumer project without their approval.  This results in the shared image showing up in the image list for the consumer project.  This can mislead users with roles in the consumer project into running a potentially malicious image. 

The Image Service API v2.1 makes image sharing a two-step process.  An image producer must add a consumer as a member of the image, and the consumer must accept the shared image before it shows up in their image list.  This additional approval process allows a consumer to control what images show up in their image list, thus preventing potentially malicious images being used without the consumers knowledge

### Recommended Actions ###
In the OpenStack Diablo, Essex, and Folsom releases, Glance supports image sharing using the Image Service API v1.  There is no way to require approval of a shared image by consumer projects.  Users should be cautioned to be careful when using images from their image list, as they may be using an image that was shared with them without their knowledge. 

In the OpenStack Grizzly and Havana releases, Glance supports the Image Service API v2.1 or later.  Support is still provided for Image Service API v1, which allows image sharing between projects without consumer project approval.  It is recommended to disable v1 of the Image Service API if possible.  This can be done by setting the following directive in the glance-api.conf configuration file:

This looks good, but I do agree with Bryan's suggestion.  I suspect it could be added as a small clarification to the second paragraph of the discussion section (which looks to need a trailing period as well.) 

### Summary ###
Glance allows images to be shared between projects.  In certain API versions, images can be shared without the consumer project's approval.  This allows potentially malicious images to show up in a project's image list. 

### Discussion ###
Since the OpenStack Diablo release, Glance allows images to be shared between projects.  To share an image, the producer of the image adds the consumer project as a member of the image.  When using the Image Service API v1, the image producer is able to share an image with a consumer project without their approval.  This results in the shared image showing up in the image list for the consumer project.  This can mislead users with roles in the consumer project into running a potentially malicious image. 

The Image Service API v2.0 does not allow image sharing between projects, so a project is not susceptible to running unauthorized images shared by other projects.  The Image Service API v2.1 allows image sharing using a two-step process.  An image producer must add a consumer as a member of the image, and the consumer must accept the shared image before it shows up in their image list.  This additional approval process allows a consumer to control what images show up in their image list, thus preventing potentially malicious images being used without the consumers knowledge. 

### Recommended Actions ###
In the OpenStack Diablo, Essex, and Folsom releases, Glance supports image sharing using the Image Service API v1.  There is no way to require approval of a shared image by consumer projects.  Users should be cautioned to be careful when using images from their image list, as they may be using an image that was shared with them without their knowledge. 

In the OpenStack Grizzly and Havana releases, Glance supports the Image Service API v2.1 or later.  Support is still provided for Image Service API v1, which allows image sharing between projects without consumer project approval.  It is recommended to disable v1 of the Image Service API if possible.  This can be done by setting the following directive in the glance-api.conf configuration file: