[PATCH] docs: Add security considerations for migration

[PATCH] docs: Add security considerations for migration

[Fabiano Rosas]

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.
+
 Sensitive configurations
 ------------------------
 
-- 
2.53.0

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

[Peter Xu]

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>

Reviewed-by: Peter Xu <peterx@redhat.com>

-- 
Peter Xu

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

[Daniel P. Berrangé]

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

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

[Fabiano Rosas]

Daniel P. Berrangé <berrange@redhat.com> writes:

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

The tone of the "Isolation mechanisms" sections is a non-prescriptive
one, so for consistency "can" is more fitting, IMO. The addition about
untrusted networks already serves to indicate that there's no other
option (untrusted network without TLS). I'll add that part in v2.

> None the less, 
>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>

Thank you, I appreciate your guidance in these matters, it's always very
helpful.

>
>
> With regards,
> Daniel