Re: [Qemu-devel] [PULL v4 00/38] Test and build patches

[Daniel P. Berrange]

On Fri, Sep 15, 2017 at 08:21:53PM +0800, Fam Zheng wrote:
> On Fri, 09/15 12:40, Daniel P. Berrange wrote:
> > On Fri, Sep 15, 2017 at 11:55:44AM +0100, Peter Maydell wrote:
> > > On 15 September 2017 at 10:02, Fam Zheng <address@hidden> wrote:
> > > > The following changes since commit 
> > > > 04ef33052c205170c92df21ca0b4be4f3b102188:
> > > >
> > > >   tcg/tci: do not use ldst label (never implemented) (2017-09-11 
> > > > 19:24:05 +0100)
> > > >
> > > > are available in the git repository at:
> > > >
> > > >   git://github.com/famz/qemu.git tags/test-and-build-pull-request
> > > >
> > > > for you to fetch changes up to be78fe670401af14e6d63fce5c5467f751207871:
> > > >
> > > >   buildsys: Move rdma libs to per object (2017-09-15 15:05:24 +0800)
> > > >
> > > > ----------------------------------------------------------------
> > > >
> > > > ----------------------------------------------------------------
> > > >
> > > > Alex Bennée (4):
> > > >   docker: ensure NOUSER for travis images
> > > >   docker: docker.py make --no-cache skip checksum test
> > > >   docker: don't install device-tree-compiler build-deps in travis.docker
> > > >   docker: reduce noise when building travis.docker
> > > >
> > > > Fam Zheng (34):
> > > >   docker: Update ubuntu image
> > > >   docker: Enable features explicitly in test-full
> > > >   tests/docker: Clean up paths
> > > >   gitignore: Ignore vm test images
> > > >   qemu.py: Add "wait()" method
> > > >   scripts: Add archive-source.sh
> > > >   tests: Add a test key pair
> > > 
> > > So, before I commit an ssh private key to our git repo,
> > > can you explain why it's ok that this is public? The
> > > commit message for the relevant patch doesn't really say.
> > 
> > IIUC, the public part of the key gets exposed to the guest images via
> > cloud-init metadata. During boot the guest read this metadata and add
> > the public key to authorized_keys. The private key is used by the test
> > suite on the host so that it can now login to the guests.
> > 
> > So the risk here is that if these guests were exposed to the LAN in any
> > way, someone could grab our private key and login to these guests.
> > 
> > What saves us is that the VMs are run with user mode slirp networking
> > so AFAICT, aren't exposed to the LAN.  So as long as we don't change
> > this to any kind of real networking, I think its acceptable to have
> > the private key in it and doesn't expose developer's workstations to
> > undue risk and avoids consuming system entropy to generate new keys
> > during build.
> 
> The hostfwd does listen on a dynamic port on 0.0.0.0, so does vnc. I didn't
> really care since it's for temporary guests and for me convenience outweighed 
> a
> bit.  The VM test is indeed less restricted than the docker ones such as in 
> that
> network is always available. Should it be a problem?

AFAICT there's no functional reason why it needs to listen on 0.0.0.0,
instead of 127.0.0.1, so general security best practice says it should
not expose this listening port on LAN interfaces for the developers
machine, even if we think the risk is low.

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