Open Stack

On 17/11/15 17:44 +0000, Daniel P. Berrange wrote:
>On Tue, Nov 17, 2015 at 02:09:42PM -0300, Flavio Percoco wrote:
>> On 13/11/15 09:35 +0000, Daniel P. Berrange wrote:
>> >On Thu, Nov 12, 2015 at 08:30:53PM +0000, Poulos, Brianna L. wrote:
>> >>Hello,
>> >>
>> >>There has recently been additional discussion about the best way to handle
>> >>image signature verification in glance and nova [1].  There are two
>> >>options being discussed for the signature (the examples below using
>> >>'RSA-PSS' as the type, and SHA-256 as the hash method):
>> >>
>> >>1. The signature is of the glance checksum of the image data (currently a
>> >>hash which is hardcoded to be MD5)
>> >>signature = RSA-PSS(SHA-256(MD5(IMAGE-CONTENT)))
>> >>
>> >>2. The signature of the image data directly
>> >>signature = RSA-PSS(SHA-256(IMAGE-CONTENT))
>> >>
>> >>The 1st option is what is currently in glance's liberty release [2].  This
>> >>approach was chosen with the understanding that the glance checksum would
>> >>be updated to be configurable [3].  Although the 2nd option was initially
>> >>proposed, the glance community opposed it during the pre-Liberty virtual
>> >>mini-summit in May 2015 (due to the performance impact of doing two hashes
>> >>of the image data--one for the 'checksum' and the other for the
>> >>signature), and it was decided to proceed with the 1st option during the
>> >>Liberty summit [4].
>> >>
>> >>During the Mitaka Summit, making the glance checksum configurable was
>> >>discussed during a design session [5].  It was decided that instead of
>> >>making the 'checksum' image field configurable, it would be preferable to
>> >>compute a separate, configurable (on a per-image basis, with a site-wide
>> >>default) hash, and then use that hash when MD5 wasn't sufficient (such as
>> >>in the case of signature verification). This second hash would be computed
>> >>at the same time the MD5 'checksum' was computed.
>> >>
>> >>Which brings us to the nova spec which is under discussion [1], which is
>> >>to add the ability to verify signatures in nova.  The nova community has
>> >>made it clear that the promise of providing a configurable hash in glance
>> >>is not good enough--they never want to support any signatures that use MD5
>> >>in any way, shape, or form; nor do they want to rely on asking glance for
>> >>what hash option was used.  To that end, the push is to use the 2nd option
>> >>to verify signatures in nova from the start.
>> >
>> >As well as not wanting MD5, I believe that computing signatures based
>> >on a configurable checksum in glance provides a bad user experiance.
>> >The user generating the signature of their image, now has to have a
>> >way to query glance to find out what checksum it used, in order to
>> >generate their signature. Further if the glance admin ever wants to
>> >change their checksum algorithm, they'd break all existing signatures
>> >by doing so. These are just as important reasons why I want Nova
>> >to use the 2nd option and compute signatures directly on the image
>> >content.
>>
>> This is a very good point. Thanks for bringing it up, Dan.
>>
>> >
>> >>Since the glance community no longer seems opposed to the idea of
>> >>computing two hashes (the second hash being optional, of course), the 2nd
>> >>option has now become valid from the glance perspective.  This would
>> >>require modifying the existing implementation in glance to verify a
>> >>signature of the image data, rather than verifying a checksum of the image
>> >>data, but would have no additional performance hit beyond the cost to
>> >>compute the second hash.  Note that the image data would still only be
>> >>read once -- the checksum update (for the MD5 hash) and the signature
>> >>verification update (for the signature hash) would occur in the same loop.
>> >>Although this would mean that signatures generated using option 1 would no
>> >>longer verify, since signatures generated using option 1 are based on an
>> >>MD5 hash (and were waiting for the checksum configurability before
>> >>becoming a viable cryptographic option anyway), this does not pose a
>> >>significant issue.
>> >
>> >A second point about the current proposal from Nova's POV is that
>> >we do not like the image property names currently used. In Liberty
>> >Nova standardized on the property naming scheme it uses to have 3
>> >naming prefixes
>> >
>> > https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L166
>> >
>> >- 'hw_' - properties that affect virtual hardware configuration
>> >- 'os_' - properties that affect guest OS setup / configuration
>> >- 'img_' - properties that affect handling of images by the host
>> >
>> >The signature properties are obviously all related to the handling
>> >of images by the host, so from Nova's POV we should have an 'img_'
>> >prefix on all their names.
>> >
>> >We probably should have alerted glance devs to this naming convention
>> >before now to avoid this problem, but I guess we forgot. It would be
>> >great if glance devs could bear this preferred naming convention in
>> >mind if there are any future cases where there is a property that
>> >needs to be used by both Nova & Glance code.
>>
>> +1
>>
>> Honestly, I wasn't aware there was such a convention. It's sad that we
>> didn't know this before adding the signature field.
>>
>> >Anyway since the change in the way we calculate signatures on images
>> >is a non-backwards compatible change for users of the current glance
>> >impl, changing these property names at this point is reasonable todo.
>> >
>> >Glance could use the property name to determine whether it is
>> >getting an old or new style signature. ie if the image property
>> >is named 'signature' then it can run RSA-PSS(SHA-256(MD5(IMAGE-CONTENT)))
>> >whereas if the name is 'img_signature' it can run the new
>> >approach RSA-PSS(SHA-256(IMAGE-CONTENT)). This allows glance
>> >a period of deprecation for the old scheme - it can support
>> >'signature' for Mitaka so anyone who used this feature from
>> >Liberty has a grace period in which they can switch to the
>> >new signature method, before support is dropped.
>>
>> This sounds good to me and it looks like an easy-enough plan to move
>> this work forward.
>>
>> >>Also note that the verification in glance is provided as a benefit to the
>> >>user, so that the user can know that the signature properties were defined
>> >>correctly at upload, rather than having to wait until the image is booted
>> >>by nova to see a signature verification fail due to an improperly-defined
>> >>signature property.  However, the main purpose of the image signature
>> >>verification feature is to provide a guarantee between when a user signs
>> >>it and when nova boots it, and so it is more important to have the
>> >>verification occur in nova.
>> >>
>> >>It would be beneficial to have a consistent approach between both the nova
>> >>and glance projects (and any future projects that make use of signature
>> >>verification).  Otherwise, the feature is not likely to be used by anyone.
>> >>
>> >>Is anyone opposed to proceeding with using option 2, in both glance and
>> >>nova?
>> >
>> >Per the spec, I'm obviously in favour of option 2 :-)
>>
>> I honestly don't mind having it in Glance and, as far as the new
>> import process goes, this would fit great into its own task.
>>
>> Brianna, it'd be awesome if you could update your spec in glance to
>> reflect this so we can move the discussion/implementation forward.
>> Pls, do mention this thread there :)
>>
>> Thanks Brianna and thanks Dan,
>
>BTW, another thing I should point out is that from a technical POV,
>having an image signature arguably obsoletes the need for glance
>to continue maintaining checksums on images at all. Instead glance
>could have its own signing key, and for any image which doesn't have
>a tenant user provided signature, glance could calculate a
>self-signature to store.
>
>Obviously from Nova's POV a glance self-signature would be less
>trustworthy than a tenant user signature, as it only protects
>against compromise of the glance <-> nova network channel or
>glance storage backend, but not against a compromise of the
>glance database / API server. A self-signature is still more
>trustworthy than an MD5 sum though, so still a net win IMHO.
>
>I imagine you probably need to keep the MD5 sig around in glance
>for sake of public REST API compatibility though, so just really
>throwing this out here as a point of interest.

This is exactly why we're keeping it around. It's a pure compatibility
issue w.r.t the public REST API rather than us willing to have both.

Thanks again,
Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151117/73a9311e/attachment.pgp>