[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH 1/3] nbd: Add option to disallow li
From: |
Daniel P . Berrangé |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH 1/3] nbd: Add option to disallow listing exports |
Date: |
Mon, 16 Apr 2018 12:00:23 +0100 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
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 :|
[Qemu-block] [PATCH 3/3] qemu-iotests: Test new qemu-nbd --nolist option, Nir Soffer, 2018/04/13