On Mon, Mar 04, 2019 at 05:09:00PM +0000, Daniel P. Berrangé wrote: > On Tue, Feb 19, 2019 at 09:07:08PM -0600, Corey Minyard wrote: > > My suggestion, though, would be to implement something that ran over > > TLS with two-way authentication. It doesn't look too hard to do > > in qemu (though I haven't tried it) but you could have a qemu console > > running over TLS that would allow you control from another qemu session. > > Plus it would give you authorization and encryption on your qemu > > console logins, which is probably a good thing. > > > > <shameless-plug> I have been working on a library that makes it easy > > (easier? The pain is always in the key management) to make TLS > > connections. It's at https://github.com/cminyard/gensio and you > > can use it from C or Python.</shameless-plug> > > On the QEMU side, we already have a framework for doing socket > connections with TLS support in a straightforward manner via > the QIOChannel framework. The code using this in QEMU doesn't > really need to know anything about TLS in order to use this. > We have it wired up in character devices, VNC, migration and > NBD network sockets.
Right, I wasn't clear, that was for the client side, not the qemu side. I saw that the TLS code was already present in qemu; no qemu modifications should be required. > > Last week my authorization series merged, so that we can also > easily deal with access control whitelisting permitted clients > via their x509 certificate distinguished name. That's even better. Thanks, -corey > > So I'd expect anything on the QEMU side that introduces new > network sockets usage to support TLS out of the box with > little extra effort required over plain TCP sockets. > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
