Re: [Qemu-devel] [PATCH v3 0/3] Use QCryptoSecret for block device passwords

[Paolo Bonzini <pbonzini@redhat.com>]

On 19/01/2016 17:46, Daniel P. Berrange wrote:
> On Tue, Jan 19, 2016 at 05:32:35PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 19/01/2016 14:51, Daniel P. Berrange wrote:
>>> This series was previously posted:
>>>
>>>   v1: https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg04365.html
>>>   v2: https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg03809.html
>>>
>>> The RBD, Curl and iSCSI block device drivers all need the ability
>>> to accept a password to authenticate with the remote network storage
>>> server. Currently RBD and iSCSI both just take the password in clear
>>> text as part of the block parameters which is insecure (passwords are
>>> visible in the process listing), while Curl doesn't support auth at
>>> all.
>>>
>>> This series updates all three drivers so that they use the recently
>>> merged QCryptoSecret API for getting passwords. Each driver gains
>>> a 'passwordid' property that can be set to provide the ID of a
>>> QCryptoSecret object instance, which in turn provides the actual
>>> password data.
>>>
>>> This series is required in order to fix a long standing CVE security
>>> flaw in libvirt, whereby passwords are exposed in the command line
>>> arguments and so visible in process listing
>>>
>>> This series would benefit from the --object additions to qemu-img,
>>> qemu-io and qemu-nbd, but this is not a pre-requisite for its merge
>>> as it us still useful in the system emulator without that support:
>>>
>>>   https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg03381.html
>>>
>>> Changed in v3:
>>>
>>>  - Rename 'passwordid' to 'password-id', 'proxypasswordid'
>>>    to 'proxy-password-id' and 'proxyusername' to 'proxy-username'
>>>    (Markus)
>>>
>>> Daniel P. Berrange (3):
>>>   rbd: add support for getting password from QCryptoSecret object
>>>   curl: add support for HTTP authentication parameters
>>>   iscsi: add support for getting CHAP password via QCryptoSecret API
>>>
>>>  block/curl.c  | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  block/iscsi.c | 24 +++++++++++++++++++++-
>>>  block/rbd.c   | 47 ++++++++++++++++++++++++++++++++++++++++++
>>>  3 files changed, 136 insertions(+), 1 deletion(-)
>>>
>>
>> Apologizing in advance for bikeshedding: what about using proxy-secret
>> and secret instead?  Traditionally the name of object options has
>> referred to the name of the class.
> 
> I wanted to avoid using the word 'secret', because in the future when we
> have ability to run LUKS encryption over any backend, we will have need
> to pass multiple secrets for a single drive spec. For example, we'll need
> one secret to provide the RBD password, and one secret to provide the LUKS
> decryption passphrase. So I felt using 'password' is a better choice to
> standardize on for the protocol authentication needs.

If you have a qcow2->luks->rbd tree, the LUKS passphrase would be
file.secret, while the rbd credentials would be file.file.username and
file.file.secret.

password-secret and proxy-password-secret are fine too.  I just don't
like "id" too much.

Paolo