From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoCwo-0001rV-HU for qemu-devel@nongnu.org; Mon, 19 Oct 2015 12:06:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoCwj-0002NQ-Gu for qemu-devel@nongnu.org; Mon, 19 Oct 2015 12:06:06 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:38061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoCwj-0002NF-9T for qemu-devel@nongnu.org; Mon, 19 Oct 2015 12:06:01 -0400 Received: by wicll6 with SMTP id ll6so12978292wic.1 for ; Mon, 19 Oct 2015 09:06:00 -0700 (PDT) References: <1445267389-21846-1-git-send-email-berrange@redhat.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <1445267389-21846-1-git-send-email-berrange@redhat.com> Date: Mon, 19 Oct 2015 17:05:58 +0100 Message-ID: <87r3kqetcp.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 00/17] Framework for securely passing secrets to QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , Josh Durgin , Stefan Hajnoczi , qemu-block@nongnu.org, qemu-devel@nongnu.org, Markus Armbruster , Ronnie Sahlberg , Paolo Bonzini Daniel P. Berrange writes: > There are a variety of places where QEMU needs to have access > to passwords, encryption keys or similar kinds of secrets. > > > Example usage for creating secrets... > > Direct password, insecure, for ad-hoc developer testing only > > $QEMU -object secret,id=sec0,data=letmein > > Indirect password via a file, good for production > > echo -n "letmein" > mypasswd.txt > $QEMU -object secret,id=sec0,file=mypasswd.txt > > The file based approach supports file descriptor passing, > so mgmt apps can use that to dynamically add passwords to > running QEMU. > > There is a better way though, which is to use an encrypted > secret. The intent here is that a mgmt app (like libvirt) > will generate a random AES-256 key for each virtual machine > it starts (saved in eg /var/run/libvirt/qemu/$GUEST.key) > It can then use the direct password passing, but encrypt > the data. > > $QEMU \ > -object secret,id=secmaster0,file=/var/run/libvirt/qemu/$GUEST.key,format=base64 \ > -object secret,id=sec0,data=[base64 ciphertext],\ > keyid=secmaster0,iv=[base64 initialization vector] > > This means that the mgmt app does not need to worry about > file descriptor passing at all. It can just use regular > object properties, safe in the knowledge that the data is > protected by a secret AES key shared only between QEMU > and the mgmt app. > > Use of encrypted secrets is not restricted to directly > provided inline data. If the secret is stored in an > external file, that can be encrypted too > > $QEMU \ > -object secret,id=secmaster0,file=/var/run/libvirt/qemu/$GUEST.key,format=base64 \ > -object secret,id=sec0,file=/some/secret/file.aes,\ > keyid=secmaster0,iv=[base64 initialization vector] > > > > Example usage for referencing secrets... > > CURL: > > $QEMU -object secret,id=sec0... \ > -drive driver=http,url=http://example.com/someimg.qcow2,\ > user=dan,passwordid=sec0 > > $QEMU -object secret,id=sec0... -object secret,id=sec1 \ > -drive driver=http,url=http://example.com/someimg.qcow2,\ > user=dan,passwordid=sec0,proxyuser=dan,passwordid=sec1 > > iSCSI: > > $QEMU -object secret,id=sec0... \ > -drive driver=iscsi,url=iscsi://example.com/target-foo/lun1,\ > user=dan,passwordid=sec0 > > RBD: > > $QEMU -object secret,id=sec0... \ > -drive driver=rbd,file=rbd:pool/image:id=myname,\ > auth-supported-cephx,authsecret=sec0 > > QCow/Qcow2 encryption > > $QEMU -object secret,id=sec0... \ > -drive file=someimage.qcow2,keyid=sec0 So one use case which I don't see here but do on other programs that need to access secrets is calling an external program and reading its stdout. This is simpler than having to mess around with passing FDs although there may be security concerns having QEMU create new tasks on the system. -- Alex Bennée