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

[Richard W.M. Jones]

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/