Re: [Qemu-devel] [PATCH 00/17] Framework for securely passing secrets to QEMU

[Daniel P. Berrange]

On Mon, Oct 19, 2015 at 05:05:58PM +0100, Alex Bennée wrote:
> Daniel P. Berrange <address@hidden> writes:
> 
> > There are a variety of places where QEMU needs to have access
> > to passwords, encryption keys or similar kinds of secrets.
> >
> <snip>
> >
> > 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.

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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|