[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 :|
Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface, no-reply, 2019/07/03
Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface, Markus Armbruster, 2019/07/05