Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface

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

On Thu, Jul 04, 2019 at 10:16:20AM +0100, Alex Bennée wrote:
> 
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Wed, Jul 03, 2019 at 10:56:05PM +0100, Alex Bennée wrote:
> >>
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> <snip>
> >> > The reality is that the monitor console (whether QMP or HMP) is
> >> > considered a privileged interface to QEMU and as such must only
> >> > be made available to trusted users. IOW, making it available with
> >> > no authentication over TCP is simply a, very serious, user
> >> > configuration error not a security flaw in QEMU itself.
> >>
> >> Is this the sort of thing we should emit warnings for? I guess this is a
> >> philosophical question as QEMU tends to err towards being taciturn on
> >> the command line unless something is actually wrong (and not just
> >> stupid).
> >>
> >> I wouldn't expect a warning for -serial mon:stdio but maybe a
> >> non-localhost tcp chardev for o+rw socket might be worth a mention? Of
> >> course this sort of sanitising of the command line options does incur
> >> cost and complexity in our option processing.
> >
> > The challenge with issuing warnings is ensuring that we don't give
> > false positives, and that's pretty much impossible IMHO.
> >
> > Even use of plain non-localhost TCP chardevs can be valid in some
> > circumstances. For example it would not be surprising to see it
> > used if QEMU was inside a Kubernetes container, as two containers
> > can communicate with each other over IP & rely on Kubernetes
> > networking layer to provide security
> 
> That's certainly a valid setup - you're right this is really a policy
> question. Oh well I guess if your serious about security you read the
> documentation before going to production right ;-)
> 
> I assume libvirt et all strive to use secure configurations by default?

Yes, libvirt exclusively uses a UNIX domain socket for the monitor, and
of course even if we used a TCP socket, the SELinux/AppArmour policy
will block any attempts at elevating privs via QMP commands that spawn
processes or try to access arbitrary files.


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