Re: [PATCH 02/13] qcrypto-luks: implement encryption key management

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Feb 05, 2020 at 10:30:11AM +0100, Kevin Wolf wrote:
>> Am 05.02.2020 um 09:24 hat Markus Armbruster geschrieben:
>> > Daniel, Kevin, any comments or objections to the QAPI schema design
>> > sketch developed below?
>> > 
>> > For your convenience, here's the result again:
>> > 
>> >     { 'enum': 'LUKSKeyslotState',
>> >       'data': [ 'active', 'inactive' ] }
>> >     { 'struct': 'LUKSKeyslotActive',
>> >       'data': { 'secret': 'str',
>> >                 '*iter-time': 'int } }
>> >     { 'union': 'LUKSKeyslotAmend',
>> >       'base': { '*keyslot': 'int',
>> >                 'state': 'LUKSKeyslotState' }
>> >       'discriminator': 'state',
>> >       'data': { 'active': 'LUKSKeyslotActive' } }
>
> We need 'secret' in the 'inactive' case too

Yes, my mistake.

>> I think one of the requirements was that you can specify the keyslot not
>> only by using its number, but also by specifying the old secret. Trivial
>> extension, you just get another optional field that can be specified
>> instead of 'keyslot'.
>> 
>> Resulting commands:
>> 
>>     Adding a key:
>>     qemu-img amend -o encrypt.keys.0.state=active,encrypt.keys.0.secret=sec0 test.qcow2
>> 
>>     Deleting a key:
>>     qemu-img amend -o encrypt.keys.0.state=inactive,encrypt.keys.0.keyslot=2 test.qcow2
>
> I think this is good as a design.
>
> Expanding the examples to cover all scenarios we've discussed
>
>
>   - Activating a new keyslot, auto-picking slot
>
>      qemu-img amend -o encrypt.keys.0.state=active,\
>                        encrypt.keys.0.secret=sec0 \
> 		    test.qcow2
>
>     Must raise an error if no free slots
>
>
>   - Activating a new keyslot, picking a specific slot
>
>      qemu-img amend -o encrypt.keys.0.state=active,\
>                        encrypt.keys.0.secret=sec0 \
> 		       encrypt.keys.0.keyslot=3 \
> 		    test.qcow2
>
>     Must raise an error if slot is already active

From the "describe desired state" point of view:

* Always suceeds when slot is inactive

* No-op when active and its secret is already the desired secret

* Must raise "in place update refused" error otherwise

>   - Deactivating a old keyslot, auto-picking slot(s) from existing password
>
>      qemu-img amend -o encrypt.keys.0.state=inactive,\
>                        encrypt.keys.0.secret=sec0 \
> 		    test.qcow2
>
>     Must raise an error if this would leave zero keyslots
>     after processing.
>
>
>   - Deactivating a old keyslot, picking a specific slot
>
>      qemu-img amend -o encrypt.keys.0.state=inactive,\
>                        encrypt.keys.0.keyslot=2 \
> 		    test.qcow2
>
>     Always succeeds even if zero keyslots left.

This one's dangerous.

Here's a variation: permit operations that may or will lose data only
with 'force': true.

When @keyslot is absent, using force has no effect.

When @keyslot is present, using force permits update in place and
deactivating the last slot.