From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoD5b-00059D-Ki for qemu-devel@nongnu.org; Mon, 19 Oct 2015 12:15:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoD5a-0005E3-B5 for qemu-devel@nongnu.org; Mon, 19 Oct 2015 12:15:11 -0400 Date: Mon, 19 Oct 2015 17:14:56 +0100 From: "Daniel P. Berrange" Message-ID: <20151019161456.GE17892@redhat.com> References: <1445267389-21846-1-git-send-email-berrange@redhat.com> <87r3kqetcp.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87r3kqetcp.fsf@linaro.org> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 00/17] Framework for securely passing secrets to QEMU Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex =?utf-8?Q?Benn=C3=A9e?= Cc: Kevin Wolf , Josh Durgin , Stefan Hajnoczi , qemu-block@nongnu.org, qemu-devel@nongnu.org, Markus Armbruster , Ronnie Sahlberg , Paolo Bonzini On Mon, Oct 19, 2015 at 05:05:58PM +0100, Alex Benn=C3=A9e wrote: > Daniel P. Berrange writes: >=20 > > 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=3Dsec0,data=3Dletmein > > > > Indirect password via a file, good for production > > > > echo -n "letmein" > mypasswd.txt > > $QEMU -object secret,id=3Dsec0,file=3Dmypasswd.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=3Dsecmaster0,file=3D/var/run/libvirt/qemu/$GUES= T.key,format=3Dbase64 \ > > -object secret,id=3Dsec0,data=3D[base64 ciphertext],\ > > keyid=3Dsecmaster0,iv=3D[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=3Dsecmaster0,file=3D/var/run/libvirt/qemu/$GUES= T.key,format=3Dbase64 \ > > -object secret,id=3Dsec0,file=3D/some/secret/file.aes,\ > > keyid=3Dsecmaster0,iv=3D[base64 initialization vector] > > > > > > > > Example usage for referencing secrets... > > > > CURL: > > > > $QEMU -object secret,id=3Dsec0... \ > > -drive driver=3Dhttp,url=3Dhttp://example.com/someimg.qcow2,\ > > user=3Ddan,passwordid=3Dsec0 > > > > $QEMU -object secret,id=3Dsec0... -object secret,id=3Dsec1 \ > > -drive driver=3Dhttp,url=3Dhttp://example.com/someimg.qcow2,\ > > user=3Ddan,passwordid=3Dsec0,proxyuser=3Ddan,passwordid= =3Dsec1 > > > > iSCSI: > > > > $QEMU -object secret,id=3Dsec0... \ > > -drive driver=3Discsi,url=3Discsi://example.com/target-foo/lun1,= \ > > user=3Ddan,passwordid=3Dsec0 > > > > RBD: > > > > $QEMU -object secret,id=3Dsec0... \ > > -drive driver=3Drbd,file=3Drbd:pool/image:id=3Dmyname,\ > > auth-supported-cephx,authsecret=3Dsec0 > > > > QCow/Qcow2 encryption > > > > $QEMU -object secret,id=3Dsec0... \ > > -drive file=3Dsomeimage.qcow2,keyid=3Dsec0 >=20 > 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. Spawning external programs is a rather heavyweight approach. I can see it being useful if you were locked into an existing API/syntax which you couldn't modify, but we don't have that restriction here. I'm also not a huge fan of having QEMU spawn a program that potentially has access to a large number of passwords that QEMU should not be able to access. I think passing in the required passwords explicitly as done here is a better approach. As noted earlier, FD passing is supported, but I don't think it is going to be commonly needed or used. At least libvirt would not use it, as providing the passwords directly, with encryption, is a more straightforward approach to implement. Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|