[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] q
From: |
Daniel P . Berrangé |
Subject: |
Re: QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management) |
Date: |
Mon, 24 Feb 2020 14:45:02 +0000 |
User-agent: |
Mutt/1.13.3 (2020-01-12) |
On Sat, Feb 15, 2020 at 03:51:46PM +0100, Markus Armbruster wrote:
> Review of this patch led to a lengthy QAPI schema design discussion.
> Let me try to condense it into a concrete proposal.
>
> This is about the QAPI schema, and therefore about QMP. The
> human-friendly interface is out of scope. Not because it's not
> important (it clearly is!), only because we need to *focus* to have a
> chance at success.
OK
> I'm going to include a few design options. I'll mark them "Option:".
>
> The proposed "amend" interface takes a specification of desired state,
> and figures out how to get from here to there by itself. LUKS keyslots
> are one part of desired state.
>
> We commonly have eight LUKS keyslots. Each keyslot is either active or
> inactive. An active keyslot holds a secret.
>
> Goal: a QAPI type for specifying desired state of LUKS keyslots.
>
> Proposal:
>
> { 'enum': 'LUKSKeyslotState',
> 'data': [ 'active', 'inactive' ] }
>
> { 'struct': 'LUKSKeyslotActive',
> 'data': { 'secret': 'str',
> '*iter-time': 'int } }
>
> { 'struct': 'LUKSKeyslotInactive',
> 'data': { '*old-secret': 'str' } }
>
> { 'union': 'LUKSKeyslotAmend',
> 'base': { '*keyslot': 'int',
> 'state': 'LUKSKeyslotState' }
> 'discriminator': 'state',
> 'data': { 'active': 'LUKSKeyslotActive',
> 'inactive': 'LUKSKeyslotInactive' } }
>
> LUKSKeyslotAmend specifies desired state for a set of keyslots.
>
> Four cases:
>
> * @state is "active"
>
> Desired state is active holding the secret given by @secret. Optional
> @iter-time tweaks key stretching.
>
> The keyslot is chosen either by the user or by the system, as follows:
>
> - @keyslot absent
>
> One inactive keyslot chosen by the system. If none exists, error.
>
> - @keyslot present
>
> The keyslot given by @keyslot.
>
> If it's already active holding @secret, no-op. Rationale: the
> current state is the desired state.
>
> If it's already active holding another secret, error. Rationale:
> update in place is unsafe.
>
> Option: delete the "already active holding @secret" case. Feels
> inelegant to me. Okay if it makes things substantially simpler.
>
> * @state is "inactive"
>
> Desired state is inactive.
>
> Error if the current state has active keyslots, but the desired state
> has none.
>
> The user choses the keyslot by number and/or by the secret it holds,
> as follows:
>
> - @keyslot absent, @old-secret present
>
> All active keyslots holding @old-secret. If none exists, error.
>
> - @keyslot present, @old-secret absent
>
> The keyslot given by @keyslot.
>
> If it's already inactive, no-op. Rationale: the current state is
> the desired state.
>
> - both @keyslot and @old-secret present
>
> The keyslot given by keyslot.
>
> If it's inactive or holds a secret other than @old-secret, error.
>
> Option: error regardless of @old-secret, if that makes things
> simpler.
>
> - neither @keyslot not @old-secret present
>
> All keyslots. Note that this will error out due to "desired state
> has no active keyslots" unless the current state has none, either.
>
> Option: error out unconditionally.
>
> Note that LUKSKeyslotAmend can specify only one desired state for
> commonly just one keyslot. Rationale: this satisfies practical needs.
> An array of LUKSKeyslotAmend could specify desired state for all
> keyslots. However, multiple array elements could then apply to the same
> slot. We'd have to specify how to resolve such conflicts, and we'd have
> to code up conflict detection. Not worth it.
>
> Examples:
>
> * Add a secret to some free keyslot:
>
> { "state": "active", "secret": "CIA/GRU/MI6" }
>
> * Deactivate all keyslots holding a secret:
>
> { "state": "inactive", "old-secret": "CIA/GRU/MI6" }
>
> * Add a secret to a specific keyslot:
>
> { "state": "active", "secret": "CIA/GRU/MI6", "keyslot": 0 }
>
> * Deactivate a specific keyslot:
>
> { "state": "inactive", "keyslot": 0 }
>
> Possibly less dangerous:
>
> { "state": "inactive", "keyslot": 0, "old-secret": "CIA/GRU/MI6" }
>
> Option: Make use of Max's patches to support optional union tag with
> default value to let us default @state to "active". I doubt this makes
> much of a difference in QMP. A human-friendly interface should probably
> be higher level anyway (Daniel pointed to cryptsetup).
>
> Option: LUKSKeyslotInactive member @old-secret could also be named
> @secret. I don't care.
>
> Option: delete @keyslot. It provides low-level slot access.
> Complicates the interface. Fine if we need lov-level slot access. Do
> we?
>
> I apologize for the time it has taken me to write this.
>
> Comments?
This is all fine with me. I have no strong opinion on the handful of
options listed above, so fine with any choices out of them.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|