On Mon, Apr 16, 2018 at 11:53:41AM +0100, Richard W.M. Jones wrote: > 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" ...
Sigh, yes, of course. > > 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. Yeah, exactly the kind of problem that hits when you mis-use a piece of traditionally public info as a security credential. > > > 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. You'll want TLS no matter what really. All SASL mechanisms, with the exception of Kerberos, require that you have a secure data channel first - which means either UNIX sockets, or TCP with TLS. If you're using SASL for auth you can, however, avoid the need to require x509 client certs. > > 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) I just mean that at the time the mgmt app sets up the NBD export, it might not know which client is going to use it, so it can't setup a x509 dname whitelist at that time. With SASL and username/password, you don't need to know who will use the export at setup time - you can simply give up username/password at time of use. 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 :|
