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

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

On Fri, Apr 13, 2018 at 10:26:03PM +0300, Nir Soffer wrote:
> When a management application expose images using qemu-nbd, it needs a
> secure way to allow temporary access to the disk. Using a random export
> name can solve this problem:
> 
>     nbd://server:10809/22965f19-9ab5-4d18-94e1-cbeb321fa433
> 
> Assuming that the url is passed to the user in a secure way, and the
> user is using TLS to access the image.
> 
> However, since qemu-nbd implements NBD_OPT_LIST, anyone can easily find
> the secret export:
> 
>     $ nbd-client -l server 10809
>     Negotiation: ..
>     22965f19-9ab5-4d18-94e1-cbeb321fa433
> 
> Add a new --nolist option, disabling listing, similar the "allowlist"
> nbd-server configuration option.
> 
> When used, listing exports will fail like this:
> 
>     $ nbd-client -l localhost 10809
>     Negotiation: ..
> 
>     E: listing not allowed by server.
>     Server said: Listing exports is forbidden

Essentially this is abusing the export name as a crude authentication
token. There are NBD servers that expect NBD_OPT_LIST to always succeeed
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.

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.

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.

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

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