yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #74330
[Bug 1593799] Re: glance-manage db purge breaks image immutability promise
The fix is in Rocky:
spec: https://specs.openstack.org/openstack/glance-
specs/specs/rocky/implemented/glance/mitigate-ossn-0075.html
code:
http://git.openstack.org/cgit/openstack/glance/commit/?h=stable/rocky&id=5cc9d999352c21d3f4b5c39d3ea9d4378ca86544
docs:
http://git.openstack.org/cgit/openstack/glance/commit/?h=stable/rocky&id=23d4e0e9c07f1ff6646e2f6236ee9625abd2a5cb
** Changed in: glance
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1593799
Title:
glance-manage db purge breaks image immutability promise
Status in Glance:
Fix Released
Status in OpenStack Security Advisory:
Opinion
Status in OpenStack Security Notes:
Fix Released
Bug description:
Using glance-manage db purge command opens possibility to recycle
image-IDs.
When the row is deleted from the database the ID is not known by
glance anymore and thus it's not unique during the deployment
lifecycle. This opens possibility to following scenario:
1) End user boots VM from private/public/shared image.
2) Image owner deletes the image.
3) glance-manage db purge gets ran which deletes record that image has ever existed.
4) Either malicious user or someone unintentionally creates new image with same ID (being same user so having access to the image by owning it or it becoming public/shared(/possbly community at some point))
5) Same end user boots either snapshot from the original image or nova needs to migrate the VM to another host. Now the user's VM will be rebuilt on top of the new image. Worst case scenario the user had no idea that the image data changed in between.
This behavior breaks Glance image immutability promise that has bee
stated that the data related to image ID that has gone active will
never change.
We have two solutions for this. Either we introduce table to track the
deleted image-IDs and get glance to cross check that during the image
create or we leave it as is but issue notice/documentation what are
the implications if the purge is used transferring the responsibility
to the cloud operators.
This was partially discussed in the virtual glance midcycle meetup so
it might not be justified to leave this as private but I wanted to
leave that decision to VMT.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1593799/+subscriptions