From: Markus Armbruster <armbru@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, qemu-devel@nongnu.org,
Maxim Levitsky <mlevitsk@redhat.com>,
Max Reitz <mreitz@redhat.com>, John Snow <jsnow@redhat.com>
Subject: Re: [PATCH 02/13] qcrypto-luks: implement encryption key management
Date: Thu, 30 Jan 2020 17:37:49 +0100 [thread overview]
Message-ID: <877e18oq76.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20200130150108.GM1891831@redhat.com> ("Daniel P. =?utf-8?Q?B?= =?utf-8?Q?errang=C3=A9=22's?= message of "Thu, 30 Jan 2020 15:01:08 +0000")
Daniel P. Berrangé <berrange@redhat.com> writes:
> On Thu, Jan 30, 2020 at 03:47:00PM +0100, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>>
>> > On Thu, Jan 30, 2020 at 01:38:47PM +0100, Kevin Wolf wrote:
>> >> Am 28.01.2020 um 18:32 hat Daniel P. Berrangé geschrieben:
>> >> > On Tue, Jan 28, 2020 at 05:11:16PM +0000, Daniel P. Berrangé wrote:
>> >> > > On Tue, Jan 21, 2020 at 03:13:01PM +0200, Maxim Levitsky wrote:
>> >> > > > On Tue, 2020-01-21 at 08:54 +0100, Markus Armbruster wrote:
>> >> > > >
>> >> > > > <trimmed>
>> >> > > >
>> >> > > > > > +##
>> >> > > > > > +# @LUKSKeyslotUpdate:
>> >> > > > > > +#
>> >> > > > > > +# @keyslot: If specified, will update only keyslot with this index
>> >> > > > > > +#
>> >> > > > > > +# @old-secret: If specified, will only update keyslots that
>> >> > > > > > +# can be opened with password which is contained in
>> >> > > > > > +# QCryptoSecret with @old-secret ID
>> >> > > > > > +#
>> >> > > > > > +# If neither @keyslot nor @old-secret is specified,
>> >> > > > > > +# first empty keyslot is selected for the update
>> >> > > > > > +#
>> >> > > > > > +# @new-secret: The ID of a QCryptoSecret object providing a new decryption
>> >> > > > > > +# key to place in all matching keyslots.
>> >> > > > > > +# null/empty string erases all matching keyslots
>> >> > > > >
>> >> > > > > I hate making the empty string do something completely different than a
>> >> > > > > non-empty string.
>> >> > > > >
>> >> > > > > What about making @new-secret optional, and have absent @new-secret
>> >> > > > > erase?
>> >> > > >
>> >> > > > I don't remember already why I and Keven Wolf decided to do this this way, but I think that you are right here.
>> >> > > > I don't mind personally to do this this way.
>> >> > > > empty string though is my addition, since its not possible to pass null on command line.
>> >> > >
>> >> > > IIUC this a result of using "StrOrNull" for this one field...
>> >> > >
>> >> > >
>> >> > > > > > +# Since: 5.0
>> >> > > > > > +##
>> >> > > > > > +{ 'struct': 'LUKSKeyslotUpdate',
>> >> > > > > > + 'data': {
>> >> > > > > > + '*keyslot': 'int',
>> >> > > > > > + '*old-secret': 'str',
>> >> > > > > > + 'new-secret' : 'StrOrNull',
>> >> > > > > > + '*iter-time' : 'int' } }
>> >> > >
>> >> > > It looks wierd here to be special casing "new-secret" to "StrOrNull"
>> >> > > instead of just marking it as an optional string field
>> >> > >
>> >> > > "*new-secret": "str"
>> >> > >
>> >> > > which would be possible to use from the command line, as you simply
>> >> > > omit the field.
>> >> > >
>> >> > > I guess the main danger here is that we're using this as a trigger
>> >> > > to erase keyslots. So simply omitting "new-secret" can result
>> >> > > in damage to the volume by accident which is not an attractive
>> >> > > mode.
>> >>
>> >> Right. It's been a while since I discussed this with Maxim, but I think
>> >> this was the motivation for me to suggest an explicit null value.
>>
>> A bit of redundancy to guard against catastrophic accidents makes sense.
>> We can discuss its shape.
>>
>> >> As long as we don't support passing null from the command line, I see
>> >> the problem with it, though. Empty string (which I think we didn't
>> >> discuss before) looks like a reasonable enough workaround to me, but if
>> >> you think this is too much magic, then maybe not.
>> >>
>> >> > Thinking about this again, I really believe we ought to be moire
>> >> > explicit about disabling the keyslot by having the "active" field.
>> >> > eg
>> >> >
>> >> > { 'struct': 'LUKSKeyslotUpdate',
>> >> > 'data': {
>> >> > 'active': 'bool',
>> >> > '*keyslot': 'int',
>> >> > '*old-secret': 'str',
>> >> > '*new-secret' : 'str',
>> >> > '*iter-time' : 'int' } }
>> >> >
>> >> > "new-secret" is thus only needed when "active" == true.
>>
>> I figure @iter-time, too.
>>
>> >> Hm. At the very least, I would make 'active' optional and default to
>> >> true, so that for adding or updating you must only specify 'new-secret'
>> >> and for deleting only 'active'.
>> >
>> > Is that asymmetry really worth while ? It merely saves a few
>> > characters of typing by omitting "active: true", so I'm not
>> > really convinced.
>> >
>> >> > This avoids the problem with being unable to specify a null for
>> >> > StrOrNull on the command line too.
>> >>
>> >> If we ever get a way to pass null on the command line, how would we
>> >> think about a struct like this? Will it still feel right, or will it
>> >> feel like we feel about simple unions today (they exist, we would like
>> >> to get rid of them, but we can't because compatibility)?
>> >
>> > Personally I really don't like the idea of using "new-secret:null"
>> > as a way to request deletion of a keyslot. That's too magical
>> > for an action that is so dangerous to data IMhO.
>>
>> I tend to agree. Expressing "zap the secret" as '"new-secret": null' is
>> clever and kind of cute, but "clever" and "cute" have no place next to
>> "irrevocably destroy data".
>>
>> > I think of these operations as activating & deactivating keyslots,
>> > hence my suggestion to use an explicit "active: true|false" to
>> > associate the core action being performed, instead of inferring
>> > the action indirectly from the secret.
>> >
>> > I think this could lend itself better to future extensions too.
>> > eg currently we're just activating or deactivating a keyslot.
>> > it is conceivable in future (LUKS2) we might want to modify an
>> > existing keyslot in some way. In that scenario, "active" can
>> > be updated to be allowed to be optional such that:
>> >
>> > - active: true -> activate a currently inactive keyslot
>> > - active: false -> deactivate a currently active keyslot
>> > - active omitted -> modify a currently active keyslot
>>
>> A boolean provides two actions. By making it optional, we can squeeze
>> out a third, at the price of making the interface unintuitive: how would
>> you know what "@active absent" means without looking it up?
>>
>> Why not have an @action of enum type instead? Values "add" and "delete"
>> now (or "activate" and "deactivate", whatever makes the most sense when
>> writing the docs), leaving us room to later add whatever comes up.
>
> I probably worded my suggestion badly - "active" should not be
> thought of as expressing an operation type; it should be considered
> a direct reflection of the "active" metadat field in a LUKS keyslot
> on disk.
>
> So I should have described it as:
>
> - active: true|false -> set the keyslot active state to this value
> - active omitted -> don't change the keyslot active state
>
> The three possible states of the "active" field then happen to
> provide the way to express the desired operations.
>
>>
>> This also lets us turn LUKSKeyslotUpdate into a union.
>>
>> Brief detour before I sketch that: update safety.
>>
>> Unless writing a keyslot is atomic, i.e. always either succeeds
>> completely, or fails without changing anything, updating a slot in place
>> is dangerous: you may destroy the old key without getting your new one
>> in place.
>>
>> To safely replace an existing secret, you first write the new secret to
>> a free slot, and only when that succeeded, you delete the old one.
>>
>> This leads to the following safe operations:
>>
>> * "Activate": write a secret to a free keyslot (chosen by the system)
>>
>> * "Deactivate": delete an existing secret from all keyslots containing
>> it (commonly just one)
>>
>> Dangerous and unwanted:
>>
>> * Replace existing secret in place
>>
>> Low-level operations we may or may not want to support:
>>
>> * Write a secret to specific keyslot (dangerous unless it's free)
>>
>> * Zap a specific keyslot (hope it contains the secret you think it does)
>>
>> Now let me sketch LUKSKeyslotUpdate as union. First without support for
>> the low-level operations:
>>
>> { state: 'LUKSKeyslotUpdateAction',
>> 'data': [ 'add', 'delete' ] }
>> { 'struct': 'LUKSKeyslotAdd',
>> 'data': { 'secret': 'str',
>> '*iter-time': 'int' } }
>> { 'struct': 'LUKSKeyslotDelete',
>> 'data': { 'secret': 'str' }
>> { 'union: 'LUKSKeyslotUpdate',
>> 'base': { 'action': 'LUKSKeyslotUpdateAction' }
>> 'discriminator': 'action',
>> 'data': { 'add': 'LUKSKeyslotAdd' },
>> { 'delete': 'LUKSKeyslotDelete' } }
>>
>> Since @secret occurs in all variants, we could also put it in @base
>> instead. Matter of taste. I think this way is clearer. Lets us easily
>> add a variant that doesn't want @secret later on (although moving it
>> from @base to variants then would be possible).
>
>
> This kind of approach is what I originally believed we
> should do, but it is contrary to the design expectations
> of the "amend" operation. That is not supposed to be
> expressing operations, rather expressing the desired
> state of the resulting disk.
I got that now, so let's talk state.
A keyslot can be either inactive or active.
Let's start low-level, i.e. we specify the slot by slot#:
state new state action
inactive inactive nop
inactive active put secret, iter-time, mark active
active inactive mark inactive (effectively deletes secret)
active active in general, error (unsafe update in place)
we can make it a nop when secret, iter-time
remain unchanged
we can allow unsafe update with force: true
As struct:
{ 'struct': 'LUKSKeyslotUpdate',
'data': { 'active': 'bool', # could do enum instead
'keyslot': 'int',
'*secret': 'str', # present if @active is true
'*iter-time': 'int' } } # absent if @active is false
As union:
{ 'enum': 'LUKSKeyslotState',
'data': [ 'active', 'inactive' ] }
{ 'struct': 'LUKSKeyslotActive',
'data': { 'secret': 'str',
'*iter-time': 'int } }
{ 'union': 'LUKSKeyslotAmend',
'base': { 'state': 'LUKSKeyslotState' } # must do enum
'discriminator': 'state',
'data': { 'active': 'LUKSKeyslotActive' } }
When we don't specify the slot#, then "new state active" selects an
inactive slot (chosen by the system, and "new state inactive selects
slots by secret (commonly just one slot).
New state active:
state new state action
inactive active put secret, iter-time, mark active
active active N/A (system choses inactive slot)
New state inactive, for each slot holding the specified secret:
state new state action
inactive inactive N/A (inactive slot holds no secret)
active inactive mark inactive (effectively deletes secret)
As struct:
{ 'struct': 'LUKSKeyslotUpdate',
'data': { 'active': 'bool', # could do enum instead
'*keyslot': 'int',
'*secret': 'str', # present if @active is true
'*iter-time': 'int' } } # absent if @active is false
As union:
{ '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' } }
Union looks more complicated because our union notation sucks[*]. I
like it anyway, because you don't have to explain when which optional
members aren't actually optional.
Regardless of struct vs. union, this supports an active -> active
transition only with an explicit keyslot. Feels fine to me. If we want
to support it without keyslot as well, we need a way to specify both old
and new secret. Do we?
[*] I hope to fix that one day. It's not even hard.
next prev parent reply other threads:[~2020-01-30 16:44 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 19:33 [PATCH 00/13] LUKS: encryption slot management using amend interface Maxim Levitsky
2020-01-14 19:33 ` [PATCH 01/13] qcrypto: add generic infrastructure for crypto options amendment Maxim Levitsky
2020-01-28 16:59 ` Daniel P. Berrangé
2020-01-29 17:49 ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 02/13] qcrypto-luks: implement encryption key management Maxim Levitsky
2020-01-21 7:54 ` Markus Armbruster
2020-01-21 13:13 ` Maxim Levitsky
2020-01-28 17:11 ` Daniel P. Berrangé
2020-01-28 17:32 ` Daniel P. Berrangé
2020-01-29 17:54 ` Maxim Levitsky
2020-01-30 12:38 ` Kevin Wolf
2020-01-30 12:53 ` Daniel P. Berrangé
2020-01-30 14:23 ` Kevin Wolf
2020-01-30 14:30 ` Daniel P. Berrangé
2020-01-30 14:53 ` Markus Armbruster
2020-01-30 14:47 ` Markus Armbruster
2020-01-30 15:01 ` Daniel P. Berrangé
2020-01-30 16:37 ` Markus Armbruster [this message]
2020-02-05 8:24 ` Markus Armbruster
2020-02-05 9:30 ` Kevin Wolf
2020-02-05 10:03 ` Markus Armbruster
2020-02-05 11:02 ` Kevin Wolf
2020-02-05 14:31 ` Markus Armbruster
2020-02-06 13:44 ` Markus Armbruster
2020-02-06 13:49 ` Daniel P. Berrangé
2020-02-06 14:20 ` Max Reitz
2020-02-05 10:23 ` Daniel P. Berrangé
2020-02-05 14:31 ` Markus Armbruster
2020-02-06 13:20 ` Markus Armbruster
2020-02-06 13:36 ` Daniel P. Berrangé
2020-02-06 14:25 ` Kevin Wolf
2020-02-06 15:19 ` Markus Armbruster
2020-02-06 15:23 ` Maxim Levitsky
2020-01-30 15:45 ` Maxim Levitsky
2020-01-28 17:21 ` Daniel P. Berrangé
2020-01-30 12:58 ` Maxim Levitsky
2020-02-15 14:51 ` QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management) Markus Armbruster
2020-02-16 8:05 ` Maxim Levitsky
2020-02-17 6:45 ` QAPI schema for desired state of LUKS keyslots Markus Armbruster
2020-02-17 8:19 ` Maxim Levitsky
2020-02-17 10:37 ` QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management) Kevin Wolf
2020-02-17 11:07 ` Maxim Levitsky
2020-02-24 14:46 ` Daniel P. Berrangé
2020-02-24 14:50 ` Maxim Levitsky
2020-02-17 12:28 ` QAPI schema for desired state of LUKS keyslots Markus Armbruster
2020-02-17 12:44 ` Eric Blake
2020-02-24 14:43 ` Daniel P. Berrangé
2020-02-24 14:45 ` QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management) Daniel P. Berrangé
2020-02-25 12:15 ` Max Reitz
2020-02-25 16:48 ` QAPI schema for desired state of LUKS keyslots Markus Armbruster
2020-02-25 17:00 ` Max Reitz
2020-02-26 7:28 ` Markus Armbruster
2020-02-26 9:18 ` Maxim Levitsky
2020-02-25 17:18 ` Daniel P. Berrangé
2020-03-03 9:18 ` QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management) Maxim Levitsky
2020-03-05 12:15 ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 03/13] block: amend: add 'force' option Maxim Levitsky
2020-01-14 19:33 ` [PATCH 04/13] block: amend: separate amend and create options for qemu-img Maxim Levitsky
2020-01-28 17:23 ` Daniel P. Berrangé
2020-01-30 15:54 ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 05/13] block/crypto: rename two functions Maxim Levitsky
2020-01-14 19:33 ` [PATCH 06/13] block/crypto: implement the encryption key management Maxim Levitsky
2020-01-28 17:27 ` Daniel P. Berrangé
2020-01-30 16:08 ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 07/13] qcow2: extend qemu-img amend interface with crypto options Maxim Levitsky
2020-01-28 17:30 ` Daniel P. Berrangé
2020-01-30 16:09 ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 08/13] iotests: filter few more luks specific create options Maxim Levitsky
2020-01-28 17:36 ` Daniel P. Berrangé
2020-01-30 16:12 ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 09/13] qemu-iotests: qemu-img tests for luks key management Maxim Levitsky
2020-01-14 19:33 ` [PATCH 10/13] block: add generic infrastructure for x-blockdev-amend qmp command Maxim Levitsky
2020-01-21 7:59 ` Markus Armbruster
2020-01-21 13:58 ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 11/13] block/crypto: implement blockdev-amend Maxim Levitsky
2020-01-28 17:40 ` Daniel P. Berrangé
2020-01-30 16:24 ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 12/13] block/qcow2: " Maxim Levitsky
2020-01-28 17:41 ` Daniel P. Berrangé
2020-01-14 19:33 ` [PATCH 13/13] iotests: add tests for blockdev-amend Maxim Levitsky
2020-01-14 21:16 ` [PATCH 00/13] LUKS: encryption slot management using amend interface no-reply
2020-01-16 14:01 ` Maxim Levitsky
2020-01-14 21:17 ` no-reply
2020-01-16 14:19 ` Maxim Levitsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877e18oq76.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).