Re: [libvirt] [PATCH 0/1] qemu: Add Secure Shell (ssh) network block device.

On Wed, Apr 10, 2013 at 03:09:18PM +0100, Richard W.M. Jones wrote: Ok, looks sensible. Hmm, yes, that's a big problem, particularly from an sVirt POV. You certainly do not want a compromised QEMU to be able to use the SSH agent to obtain your keys for logging into arbitrary remote systems. So exposing the SSH agent to QEMU directly seems like a no-go. The way that works, is that the application creating the guest has to pre-populate secrets with keys/passwords/whatever. The guest XML refers to which secrets it needs, and at guest startup Libvirt would push the secrets into QEMU. IIUC, the SSH agent protocol is fundamentally designed around the idea of "application pull", where as we want an approach which I describe as "manager push". Using secrets for passing authentication information in for disks is the right thing todo - we already do this for RBD for example. What is missing is a way to securely pass this into QEMU - for RBD we currently pass this on the command line. The guys who added RBD support to libvirt were supposed to be adding ability to pass the passwords via the monitor but that never seems to have happened. I wish we'd never allowed the patches for RBD for passing stuff on the command line, still it removed the motivation for them todo a better job. Anyway for SSH, I think we need to have this bit of QEMU finished, so we can pass in authentication credentials via the monitor. There is an existing 'block_password' command, but that was used for the decryption keys and I don't think it is wise to overload that for authentication keys too, since it is in theory possible to access an encrypted QCow2 image over the SSH protocol, in which case we would need both decryption keys and authetnication keys at the same time. The only other alternative would be to actally make libvirtd implement an SSH agent service, exposing per-VM UNIX to the QEMU process(es) which needed SSH keys. I don't much like this though, since it would only be useful to the SSH disk protocol, and not help address the problems we already face for RBD and other network block devices. 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 :|