[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v3 0/3] Use QCryptoSecret for block device passw
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-block] [PATCH v3 0/3] Use QCryptoSecret for block device passwords |
Date: |
Tue, 19 Jan 2016 21:41:31 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 |
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