qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface
Date: Wed, 3 Jul 2019 15:30:01 +0100
User-agent: Mutt/1.12.0 (2019-05-25)

On Wed, Jul 03, 2019 at 04:24:26PM +0200, Philippe Mathieu-Daudé wrote:
> On 7/3/19 3:54 PM, Daniel P. Berrangé wrote:
> > A supposed exploit of QEMU was recently announced as CVE-2019-12928
> > claiming that the monitor console was insecure because the "migrate"
> > comand enabled arbitrary command execution for a remote attacker.
> > 
> > For this to be a flaw the user launching QEMU must have configured
> > the monitor in a way that allows for other userrs to access it. The
> > exploit report quoted use of the "tcp" character device backend for
> > QMP.
> > 
> > This would indeed allow any network user to connect to QEMU and
> > execute arbitrary comamnds, however, this is not a flaw in QEMU.
> 
> comamnds -> commands
> 
> > It is the normal expected behaviour of the monitor console and the
> > commands it supports. Given a monitor connection, there are many
> > ways to access host filesystem content besides the migrate command.
> > 
> > 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.
> > 
> > The one thing this bogus security report highlights though is that
> > we have not clearly documented the security implications around the
> > use of the monitor. Add a few paragraphs of text to the security
> > docs explaining why the monitor is a privileged interface and making
> > a recommendation to only use the UNIX socket character device backend.
> > 
> > Signed-off-by: Daniel P. Berrangé <address@hidden>
> > ---
> >  docs/security.texi | 36 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 36 insertions(+)
> > 
> > diff --git a/docs/security.texi b/docs/security.texi
> > index 927764f1e6..5bff01449d 100644
> > --- a/docs/security.texi
> > +++ b/docs/security.texi
> > @@ -129,3 +129,39 @@ those resources that were granted to it.
> >  system calls that are not needed by QEMU, thereby reducing the host kernel
> >  attack surface.
> >  @end itemize
> > +
> > +@section Sensitive configurations
> > +
> > +There are aspects of QEMU that can have non-obvious security implications
> > +which users & management applications must be aware of.
> > +
> > +@subsection Monitor console (QMP and HMP)
> > +
> > +The monitor console (whether used with QMP or HMP) provides an RPC 
> > interface
> > +to dynamically control many aspects of QEMU's runtime operation. Many of 
> > the
> > +commands exposed will instruct QEMU to access content on the host 
> > filesysystem
> > +and/or trigger spawning of external processes.
> > +
> > +For example, the @code{migrate} command allows for the spawning of 
> > arbitrary
> > +processes for the purpose of tunnelling the migration data stream. The
> > +@code{blockdev-add} command instructs QEMU to open arbitrary files, 
> > exposing
> > +their content to the guest as a virtual disk.
> > +
> > +Unless QEMU is otherwise confined using technologies such as SELinux, 
> > AppArmor,
> > +or Linux namespaces, the monitor console should be considered to have 
> > privileges
> > +equivalent to those of the user account QEMU is running under.
> > +
> > +It is further important to consider the security of the character device 
> > backend
> > +over which the monitor console is exposed. It needs to have protection 
> > against
> > +malicious third parties which might try to make unauthorized connections, 
> > or
> > +perform man-in-the-middle attacks. Many of the character device backends 
> > do not
> > +satisfy this requirement and so must not be used for the monitor console.
> > +
> > +The general recommendation is that the monitor console should be exposed 
> > over
> > +a UNIX domain socket backend to the local host only. Use of the TCP based
> > +character device backend is inappropriate unless configured to use both TLS
> > +encryption and authorization control policy on client connections.
> > +
> > +In summary the monitor console is considered a privileged control 
> > interface to
> 
> I'd have written "In summary, " or "In summary: " but I'm not sure this
> is correct/better ;)

Using a comma is a reasonable thing here.

> 
> > +QEMU and as such should only be made accessible to a trusted management
> > +application or user.
> > 
> 
> Thanks for writing this down.
> 
> Reviewed-by: Philippe Mathieu-Daudé <address@hidden>

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]