Re: [Qemu-devel] [PATCH 1/3] nbd: Add option to disallow listing exports

["Daniel P. Berrangé" <berrange@redhat.com>]

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 :|