From nobody Sun Feb 8 07:21:43 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1562172981; cv=none; d=zoho.com; s=zohoarc; b=FOmVpcvrsUU5uDfpBJ4P5uKhckD96xy5ZAMJf0R+p33zRCu0Fp9gHiEAcfdTNIM85Qw4XaZm/OXmRD119YWMpYcJO7Ao+IlTk3bIci41dg8sqJA9I0dNVg7Q4trXm/h+q3SdIc/GZBnMCGU1no5AUxsoN1Zlu21EnG/SXAmzigo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1562172981; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To:ARC-Authentication-Results; bh=8BivlZSJG/4GnZsj9Fkp/1D2//HwoKw18WCV5sy7YRw=; b=d34P6Dz5Ehmgscnp00+8WLO5qsJIRe3nOP3NVz6VzjzJYG5kiEcAboYFTScIvfBVnEUhzYoV1YqEA1Pw0Ju6pxprarLUz94jYNZWiW+MiYf4wU1jQojO1eUcv48iyqUWl0ydLczTL5uZxqjQzstKPe1cFM9M1fi3KiAT/Btrj+k= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 156217298173158.268224374342026; Wed, 3 Jul 2019 09:56:21 -0700 (PDT) Received: from localhost ([::1]:37712 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiiYK-0004qw-2H for importer@patchew.org; Wed, 03 Jul 2019 12:56:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36736) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiiEd-0002yU-Cs for qemu-devel@nongnu.org; Wed, 03 Jul 2019 12:35:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiiEb-0007r0-Vr for qemu-devel@nongnu.org; Wed, 03 Jul 2019 12:35:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49432) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hiiEZ-0007oe-U9 for qemu-devel@nongnu.org; Wed, 03 Jul 2019 12:35:52 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EAA0A3082E5F; Wed, 3 Jul 2019 16:35:45 +0000 (UTC) Received: from dhcp-17-95.lcy.redhat.com (unknown [10.42.17.95]) by smtp.corp.redhat.com (Postfix) with ESMTP id 52091832B6; Wed, 3 Jul 2019 16:35:42 +0000 (UTC) From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Date: Wed, 3 Jul 2019 17:35:41 +0100 Message-Id: <20190703163541.19520-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Wed, 03 Jul 2019 16:35:45 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v2] doc: document that the monitor console is a privileged control interface X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Stefan Hajnoczi , "Dr . David Alan Gilbert" , Markus Armbruster , P J P , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" A supposed exploit of QEMU was recently announced as CVE-2019-12928 claiming that the monitor console was insecure because the "migrate" command enabled arbitrary command execution for a remote attacker. To be a security risk the user launching QEMU must have configured the monitor in a way that allows for other users 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 commands, however, this is not a flaw in QEMU. 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. Reviewed-by: Philippe Mathieu-Daud=C3=A9 Signed-off-by: Daniel P. Berrang=C3=A9 Reviewed-by: Prasad J Pandit --- Changed in v2: - Addressed misc typos (Eric / Philippe) docs/security.texi | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/docs/security.texi b/docs/security.texi index 927764f1e6..3f5d5e7adc 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 interfa= ce +to dynamically control many aspects of QEMU's runtime operation. Many of t= he +commands exposed will instruct QEMU to access content on the host filesysy= stem +and/or trigger spawning of external processes. + +For example, the @code{migrate} command allows for the spawning of arbitra= ry +processes for the purpose of tunnelling the migration data stream. The +@code{blockdev-add} command instructs QEMU to open arbitrary files, exposi= ng +their content to the guest as a virtual disk. + +Unless QEMU is otherwise confined using technologies such as SELinux, AppA= rmor, +or Linux namespaces, the monitor console should be considered to have priv= ileges +equivalent to those of the user account QEMU is running under. + +It is further important to consider the security of the character device b= ackend +over which the monitor console is exposed. It needs to have protection aga= inst +malicious third parties which might try to make unauthorized connections, = or +perform man-in-the-middle attacks. Many of the character device backends d= o 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 o= ver +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 interfa= ce to +QEMU and as such should only be made accessible to a trusted management +application or user. --=20 2.21.0