On Mon, Apr 16, 2018 at 11:31:18AM +0100, Daniel P. Berrangé wrote: > Essentially this is abusing the export name as a crude authentication > token. There are NBD servers that expect NBD_OPT_LIST to always succeeed
I guess you mean "NBD clients" ... > when they detect that the new style protocol is available. I really hate > the idea of making it possible to break the NBD_OPT_LIST functionality > via a command line arg like this. The specific use case I have in mind is virt-v2v forked an instance of ‘qemu-img convert’ which connects to the NBD server. Of course this does also reveal a flaw in the plan because ... > Furthermore, applications are *not* considering the export names to be > security sensitive data, so will not be taking any precautions to ensure > they remain secret, as they would do with authentication credentials. > Again I really hate the idea of using NBD exports an an auth credential. ‘ps ax’ on the conversion server will reveal the export name/ticket from the qemu-img command line. > So I don't think we should be suggesting that security through obscurity of > the export name is a supported approach to securing NBD. > > I understand the desire to be able to secure NBD exports though, so think > we need to come up with some kind of supportable solution for this. There > are two approaches we should take > > - Add support for TLS client certification whitelisting. eg every client > has a unique identity based on the distinguished name (dname) in the > x509 cert they were issued. The NBD server can be told which of these > dnames should be a permitted to connect. This is supported in VNC for > years, and I've had patches pending to support this in a QEMU for chardevs > NBD and migration for a while. These were stalled on way to convert > -object ... syntax into nested QOM objects. > > - Define a mapping of the SASL protocol ontop NBD. SASL is a > generic pluggable authentication mechanism for network > protocols. It is already used in libvirt, VNC and SPICE, and > would easily fit in with NBD from a conceptual POV. When used in > combination with TLS, this offers a wide range of auth mechanisms > from simple username+password, to full integration with Kerberos. The first one sounds heavyweight but at least implementable from the virt-v2v point of view. The second one sounds like it would be impossible for mere humans to set it up. > If this need is urgent, I think we could partially unblock the TLS x509 > whitelisting support without much difficulty. We haven't been pushing hard > to unblock it simply because no one was urgently blocked by its absence > so far. This provides a strong solution, but the difficulty is that the > server may not know the x509 dname of the permitted client, which makes > it hard to use in practice. Can you clarify what you mean by the last sentence above? Can't we just create a client certificate in virt-v2v and pass that to qemu-img, and at the same time pass the server a list of permitted names? (likely only a single name in practice) > SASL with a simple username+password scheme > is thus still very compelling to implement, but will obviously take longer > due to the amount of code/spec work required. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/
