From nobody Sun Feb 8 18:49:26 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) client-ip=205.139.110.61; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1574434092; cv=none; d=zohomail.com; s=zohoarc; b=LgXLg+0oj22TzAm8CP88+yKjwEB6vIg7E2KbAp4roREFwpVqJVjuNaJCUAAJhCJ0crGfm30ewRsz23L5DjhnxjGRU3KPRqzxZh0fBbXgMAVMv2u3kvFnVrFuf323lkpHSxy3WfKvHUMfB80FOyA/uWqqwdm0tRdT5V/r6W49fSs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1574434092; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=95s7f2lrR7KUBir6yI1s7Zy825NCJESRGLRxurmUBFY=; b=kf3o3i6o40uYH6EQkkBIADPf9eC7QjJE6VnRQIVcZWKcXXV8GkBVlF+2S/V8ppxuXCpk231qfBBd/15BDqvO6tZ3dJBMkCkhBTreQ3LvlAbvjY5ePVbchfAvHskexMnHo3n9rEKFAXQa0XNoWx2gBEhsrFFZlqh0SXTvjagnEy8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by mx.zohomail.com with SMTPS id 1574434092876838.2082118702104; Fri, 22 Nov 2019 06:48:12 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-120-j2th4S8pPbq6D3eKSs8XuA-1; Fri, 22 Nov 2019 09:48:04 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 199C3477; Fri, 22 Nov 2019 14:47:59 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D0F7160BD4; Fri, 22 Nov 2019 14:47:58 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 773ED4E57B; Fri, 22 Nov 2019 14:47:58 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id xAMElgas018229 for ; Fri, 22 Nov 2019 09:47:42 -0500 Received: by smtp.corp.redhat.com (Postfix) id 2386B1036C8C; Fri, 22 Nov 2019 14:47:42 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-112-49.ams2.redhat.com [10.36.112.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6BF6F1036C7E; Fri, 22 Nov 2019 14:47:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574434091; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=95s7f2lrR7KUBir6yI1s7Zy825NCJESRGLRxurmUBFY=; b=Uln8sXYzq9VNRv2y8F40FFonVRAV4uNwwLeg6KmjfgCikUtf5ckKk3A6dG3FQ2JNoIGXjI I3Zqxlq+ASGVufG4KIJgqugAuFhfdC2WdQni/Yx05E+FYKyLjoYbuwL+KJsSfNqI9VvF/x BOZUw8yK37HNsGOv+BcDLzZnRmfRRRo= From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: libvir-list@redhat.com Date: Fri, 22 Nov 2019 14:46:58 +0000 Message-Id: <20191122144702.3780548-12-berrange@redhat.com> In-Reply-To: <20191122144702.3780548-1-berrange@redhat.com> References: <20191122144702.3780548-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 11/15] docs: convert kbase/secureusage.html.in to RST X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: j2th4S8pPbq6D3eKSs8XuA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) This is a semi-automated conversion. The first conversion is done using "pandoc -f html -t rst". The result is then editted manually to apply the desired heading markup, and fix a few things that pandoc gets wrong. Signed-off-by: Daniel P. Berrang=C3=A9 --- docs/kbase/secureusage.html.in | 171 --------------------------------- docs/kbase/secureusage.rst | 131 +++++++++++++++++++++++++ 2 files changed, 131 insertions(+), 171 deletions(-) delete mode 100644 docs/kbase/secureusage.html.in create mode 100644 docs/kbase/secureusage.rst diff --git a/docs/kbase/secureusage.html.in b/docs/kbase/secureusage.html.in deleted file mode 100644 index c60187fab3..0000000000 --- a/docs/kbase/secureusage.html.in +++ /dev/null @@ -1,171 +0,0 @@ - - - - - -

Secure Usage of Libvirt

- -
    - -

    - This page details information that application developers and - administrators of libvirt should be aware of when working with - libvirt, that may have a bearing on security of the system. -

    - - -

    Disk image handling

    - -

    Disk image format probing

    - -

    - Historically there have been multiple flaws in QEMU and most - projects using QEMU, related to handling of disk formats. - The problems occur when a guest is given a virtual disk backed - by raw disk format on the host. If the management application - on the host tries to auto-detect / probe the disk format, it - is vulnerable to a malicious guest which can write a qcow2 - file header into its raw disk. If the management application - subsequently probes the disk, it will see it as a 'qcow2' disk - instead of a 'raw' disk. Since 'qcow2' disks can have a copy - on write backing file, such flaw can be leveraged to read - arbitrary files on the host. The same type of flaw may occur - if the management application allows users to upload pre-created - raw images. -

    - -

    - Recommendation: never attempt to automatically - detect the format of a disk image based on file contents which - are accessible to / originate from an untrusted source. -

    - -

    Disk image backing files

    - -

    - If a management application allows users to upload pre-created - disk images in non-raw formats, it can be tricked into giving - the user access to arbitrary host files via the copy-on-write - backing file feature. This is because the qcow2 disk format - header contains a filename field which can point to any location. - It can also point to network protocols such as NBD, HTTP, GlusterFS, - RBD and more. This could allow for compromise of almost arbitrary - data accessible on the LAN/WAN. -

    - -

    - Recommendation: always validate that a disk - image originating from an untrusted source has no backing - file set. If a backing file is seen, reject the image. -

    - -

    Disk image size validation

    - -

    - If an application allows users to upload pre-created disk - images in non-raw formats, it is essential to validate the - logical disk image size, rather than the physical disk - image size. Non-raw disk images have a grow-on-demand - capability, so a user can provide a qcow2 image that may - be only 1 MB in size, but is configured to grow to many - TB in size. -

    - -

    - Recommendation: if receiving a non-raw disk - image from an untrusted source, validate the logical image - size stored in the disk image metadata against some finite - limit. -

    - -

    Disk image data access

    - -

    - If an untrusted disk image is ever mounted on the host OS by - a management application or administrator, this opens an - avenue of attack with which to potentially compromise the - host kernel. Filesystem drivers in OS kernels are often very - complex code and thus may have bugs lurking in them. With - Linux, there are a large number of filesystem drivers, many - of which attract little security analysis attention. Linux - will helpfully probe filesystem formats if not told to use an - explicit format, allowing an attacker the ability to target - specific weak filesystem drivers. Even commonly used and - widely audited filesystems such as ext4 have had - bugs lurking in them - undetected for years at a time. -

    - -

    - Recommendation: if there is a need to access - the content of a disk image, use a single-use throwaway virtual - machine to access the data. Never mount disk images on the host - OS. Ideally make use of the libgue= stfs - tools and APIs for accessing disks -

    - -

    Guest migration network

    - -

    - Most hypervisors with support for guest migration between hosts - make use of one (or more) network connections. Typically the source - host will connect to some port on the target host to initiate the - migration. There may be separate connections for co-ordinating the - migration, transferring memory state and transferring storage. - If the network over which migration takes place is accessible the - guest, or client applications, there is potential for data leakage - via packet snooping/capture. It is also possible for a malicious - guest or client to make attempts to connect to the target host - to trigger bogus migration operations, or at least inflict a denial - of service attack. -

    - -

    - Recommendations: there are several things to consid= er - when performing migration -

    - -
      -
    • Use a specific address for establishing the migration - connection which is accessible only to the virtualization - hosts themselves, not libvirt clients or virtual guests. - Most hypervisors allow the management application to provide - the IP address of the target host as a way to - determine which network migration takes place on. This is - effectively the connect() socket address for the source host.
      • -
    • Use a specific address for listening for incoming migration - connections which is accessible only to the virtualization - hosts themselves, not libvirt clients or virtual guests. - Most hypervisors allow the management application to configure - the IP address on which the target host listens. This is - the bind() socket address for the target host.
      • -
    • Use an encrypted migration protocol. Some hypervisors - have support for encrypting the migration memory/storage - data. In other cases it can be tunnelled over the libvirtd - RPC protocol connections.
      • -
    - -

    Storage encryption

    - -

    - Virtual disk images will typically contain confidential data - belonging to the owner of the virtual machine. It is desirable - to protect this against data center administrators as much as - possible. For example, a rogue storage administrator may attempt - to access disk contents directly from a storage host, or a network - administrator/attack may attempt to snoop on data packets relating - to storage access. Use of disk encryption on the virtualization - host can ensure that only the virtualization host administrator - can see the plain text contents of disk images. -

    - -

    - Recommendation: make use of storage encryption - to protect non-local storage from attack by rogue network / - storage administrators or external attackers. This is particularly - important if the storage protocol itself does not offer any kind - of encryption capabilities. -

    - - - diff --git a/docs/kbase/secureusage.rst b/docs/kbase/secureusage.rst new file mode 100644 index 0000000000..5a631193d1 --- /dev/null +++ b/docs/kbase/secureusage.rst @@ -0,0 +1,131 @@ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Secure Usage of Libvirt +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +.. contents:: + +This page details information that application developers and +administrators of libvirt should be aware of when working with libvirt, +that may have a bearing on security of the system. + +Disk image handling +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Disk image format probing +------------------------- + +Historically there have been multiple flaws in QEMU and most projects +using QEMU, related to handling of disk formats. The problems occur when +a guest is given a virtual disk backed by raw disk format on the host. +If the management application on the host tries to auto-detect / probe +the disk format, it is vulnerable to a malicious guest which can write a +qcow2 file header into its raw disk. If the management application +subsequently probes the disk, it will see it as a 'qcow2' disk instead +of a 'raw' disk. Since 'qcow2' disks can have a copy on write backing +file, such flaw can be leveraged to read arbitrary files on the host. +The same type of flaw may occur if the management application allows +users to upload pre-created raw images. + +**Recommendation:** never attempt to automatically detect the format of +a disk image based on file contents which are accessible to / originate +from an untrusted source. + +Disk image backing files +------------------------ + +If a management application allows users to upload pre-created disk +images in non-raw formats, it can be tricked into giving the user access +to arbitrary host files via the copy-on-write backing file feature. This +is because the qcow2 disk format header contains a filename field which +can point to any location. It can also point to network protocols such +as NBD, HTTP, GlusterFS, RBD and more. This could allow for compromise +of almost arbitrary data accessible on the LAN/WAN. + +**Recommendation:** always validate that a disk image originating from +an untrusted source has no backing file set. If a backing file is seen, +reject the image. + +Disk image size validation +-------------------------- + +If an application allows users to upload pre-created disk images in +non-raw formats, it is essential to validate the logical disk image +size, rather than the physical disk image size. Non-raw disk images have +a grow-on-demand capability, so a user can provide a qcow2 image that +may be only 1 MB in size, but is configured to grow to many TB in size. + +**Recommendation:** if receiving a non-raw disk image from an untrusted +source, validate the logical image size stored in the disk image +metadata against some finite limit. + +Disk image data access +---------------------- + +If an untrusted disk image is ever mounted on the host OS by a +management application or administrator, this opens an avenue of attack +with which to potentially compromise the host kernel. Filesystem drivers +in OS kernels are often very complex code and thus may have bugs lurking +in them. With Linux, there are a large number of filesystem drivers, +many of which attract little security analysis attention. Linux will +helpfully probe filesystem formats if not told to use an explicit +format, allowing an attacker the ability to target specific weak +filesystem drivers. Even commonly used and widely audited filesystems +such as ``ext4`` have had `bugs lurking in +them `__ undetected for years at a +time. + +**Recommendation:** if there is a need to access the content of a disk +image, use a single-use throwaway virtual machine to access the data. +Never mount disk images on the host OS. Ideally make use of the +`libguestfs `__ tools and APIs for accessing +disks + +Guest migration network +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Most hypervisors with support for guest migration between hosts make use +of one (or more) network connections. Typically the source host will +connect to some port on the target host to initiate the migration. There +may be separate connections for co-ordinating the migration, +transferring memory state and transferring storage. If the network over +which migration takes place is accessible the guest, or client +applications, there is potential for data leakage via packet +snooping/capture. It is also possible for a malicious guest or client to +make attempts to connect to the target host to trigger bogus migration +operations, or at least inflict a denial of service attack. + +**Recommendations:** there are several things to consider when +performing migration + +- Use a specific address for establishing the migration connection + which is accessible only to the virtualization hosts themselves, not + libvirt clients or virtual guests. Most hypervisors allow the + management application to provide the IP address of the target host + as a way to determine which network migration takes place on. This is + effectively the connect() socket address for the source host. +- Use a specific address for listening for incoming migration + connections which is accessible only to the virtualization hosts + themselves, not libvirt clients or virtual guests. Most hypervisors + allow the management application to configure the IP address on which + the target host listens. This is the bind() socket address for the + target host. +- Use an encrypted migration protocol. Some hypervisors have support + for encrypting the migration memory/storage data. In other cases it + can be tunnelled over the libvirtd RPC protocol connections. + +Storage encryption +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Virtual disk images will typically contain confidential data belonging +to the owner of the virtual machine. It is desirable to protect this +against data center administrators as much as possible. For example, a +rogue storage administrator may attempt to access disk contents directly +from a storage host, or a network administrator/attack may attempt to +snoop on data packets relating to storage access. Use of disk encryption +on the virtualization host can ensure that only the virtualization host +administrator can see the plain text contents of disk images. + +**Recommendation:** make use of storage encryption to protect non-local +storage from attack by rogue network / storage administrators or +external attackers. This is particularly important if the storage +protocol itself does not offer any kind of encryption capabilities. --=20 2.23.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list