From: "Daniel P. Berrange" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Attila-Mihaly Balazs <dify.ltd@gmail.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Possible security enhancement for QEMU
Date: Mon, 5 Jan 2015 18:13:55 +0000 [thread overview]
Message-ID: <20150105181354.GN29381@redhat.com> (raw)
In-Reply-To: <CAFEAcA_FsHYmOieHkwW_ZJA7Lm2mnhgeUs1HG9gpVwt7tZafzA@mail.gmail.com>
On Mon, Dec 29, 2014 at 09:26:45PM +0000, Peter Maydell wrote:
> On 29 December 2014 at 19:09, Attila-Mihaly Balazs <dify.ltd@gmail.com> wrote:
> > My suggestion for improvement would be:
> > - change the behaviour of "-vnc :port" such that it listens on "127.0.0.1"
> > when the IP isn't specified
> > - if host is "0.0.0.0" (perhaps also include any routable IPv4 addresses -
> > and non-link-local IPv6 addresses) and no authentication method is specified
> > error out with a message like "It is recommended that you DO NOT expose the
> > VNC server directly to the public internet. If you are sure of what you are
> > doing, please specify an authentication method for the VNC server. See the
> > documentation for more details"
Configuring 0.0.0.0 and no auth is a valid setup *provided* the virtualization
host itself is on a secured network. In fact this is the normal setup for an
OpenStack deployment, since the virt host/VNC server is not intended to ever
be directly exposed to the internet. Instead the user accesses the VNC server
via an authenticated VNC proxy tunnelled over HTTPs. So printing out such an
error message or refusing to launch would be wrong - QEMU doesn't know the
context of how it is being used.
> Seems reasonable to me. Some questions:
> * do we need an option for "yes, I know what I'm doing and do not
> want any authentication" ?
> * how many of these VMs are configured for wide-open VNC by libvirt or
> similar management tool rather than by the user directly running QEMU?
Libvirt will always set the listen address to 127.0.0.1 if not otherwise
specified, and so not rely on QEMU's (insecure) default. So if any VMs
managed by libvirt are using a public IP address, this was requested
explicitly by the admin or the mgmt app using libvrt.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2015-01-05 18:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-29 19:09 [Qemu-devel] Possible security enhancement for QEMU Attila-Mihaly Balazs
2014-12-29 21:26 ` Peter Maydell
2015-01-05 18:13 ` Daniel P. Berrange [this message]
2015-01-05 18:20 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150105181354.GN29381@redhat.com \
--to=berrange@redhat.com \
--cc=dify.ltd@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).