Re: [PATCH] docs: Add security considerations for migration

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

On Mon, Jul 20, 2026 at 03:27:50PM -0300, Fabiano Rosas wrote:
> Add the security considerations that are unique to migration and that
> do not already fall into one of the other categories. Some aspects are
> better framed as security architecture considerations, so extend that
> section to mention TLS and clarify that disk images and guest network
> also need to be isolated from other processes, not just other guests.
> 
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
> ---
>  docs/system/security.rst | 22 ++++++++++++++++++----
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/system/security.rst b/docs/system/security.rst
> index 52bbf0cc7a2..26c686718cf 100644
> --- a/docs/system/security.rst
> +++ b/docs/system/security.rst
> @@ -133,6 +133,16 @@ an issue as a normal bug.
>    that affect the level 0 QEMU process. While these bugs should be
>    fixed, they will not be triaged as security flaws at this time.
>  
> +* **migration/snapshots**. Migration failures and snapshot load
> +  failures are considered part of normal operation as long as the
> +  source virtual machine and savevm file, respectively, are still
> +  functional. Aborting the QEMU process at the migration/snapshot
> +  destination is similarly not considered a security issue. The
> +  migration stream is assumed to be secure as long as the design
> +  principles described in the Architecture section are held, in
> +  which case plain manipulation of the stream is not considered as
> +  an attack vector.
> +
>  * **low severity impact**. As a catch all rule, issues which
>    are judged to have a "low" severity impact on the system will
>    usually not justify handling as security bugs, nor assignment
> @@ -159,10 +169,11 @@ could allow malicious guests to gain code execution in QEMU.  At this point the
>  guest has escaped the virtual machine and is able to act in the context of the
>  QEMU process on the host.
>  
> -Guests often interact with other guests and share resources with them.  A
> -malicious guest must not gain control of other guests or access their data.
> -Disk image files and network traffic must be protected from other guests unless
> -explicitly shared between them by the user.
> +Guests often interact with other guests and share resources with them.
> +A malicious guest must not gain control of other guests or access
> +their data.  Disk image files and network traffic must be protected
> +from other guests, users and processes unless explicitly shared with
> +them by the user.
>  
>  Principle of Least Privilege
>  ''''''''''''''''''''''''''''
> @@ -223,6 +234,9 @@ Some Linux distros already ship with UNIX groups for these devices by default.
>    system calls that are not needed by QEMU, thereby reducing the host kernel
>    attack surface.
>  
> +- Transport Layer Security (TLS) protocol can be used to ensure hypervisor
> +  authenticity and encryption of the live migration connection.

I'd be a bit stronger

 - Transport Layer Security (TLS) protocol should be used to ensure
   hypervisor authenticity and encryption of the live migration
   connection where the network is untrusted.

None the less, 

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>



With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|