Daniel P. Berrangé <[email protected]> writes:
> On Thu, Jul 16, 2026 at 11:08:49AM -0300, Fabiano Rosas wrote:
>> Assumptions:
>>
>> A) The migration stream is assumed to be secured by TLS on a per-host
>> basis.
>>
>> B) For migration streams stored to file, including snapshots, it is
>> assumed that the storage file is authentic, i.e. the files are owned by
>> the party performing the live migration and have not been tampered with.
>>
>> C) The network ports used for migration are expected to be available
>> only during migration. No long-standing listening destination QEMU
>> process.
>>
>> D) The network used for migration is expected to be adequately isolated.
>>
>> E) The migration source QEMU process is assumed to be secure. Compromise
>> of the source QEMU process is nonetheless possible but exploiting the
>> migration process is expected to grant no further privileges.
>
>
> In the security.rst doc, we have an "Architecture" heading where
> we outline design principals for security. The "Assumptions" feels
> like it has overlap with that section.
>
What if we tweak that section to be more broad?
- Under "Guest Isolation":
Disk image files and network traffic must be protected from other guests...
s/unless explicitly shared between/, users and processes unless explicitly
shared with/
... them by the user.
- Under Isolation Mechanisms, we can add a bullet:
- Transport Layer Security (TLS) protocol can be used to ensure
hypervisor authenticity and encryption of the live migration
connection.
I can send a separate patch with this.
>> For security consideration, the following are considered:
>>
>> OUT OF SCOPE:
>>
>> 1) Abort of destination QEMU process while migration is still in course.
>> Rationale: the source virtual machine is not affected.
>>
>> 2) Migration failure.
>> Rationale: eventual failed migrations are part of normal operation.
>>
>> 3) Memory over-allocation issues in the destination QEMU process.
>> Rationale: the destination host's operating system is expected to
>> constrain resource usage. Process termination due to OOM falls under
>> point 1 above.
>
> The "Security boundary scope" section has primarily been listing
> things that are definitely "out of scope".
>
I think the only point not yet covered is the destination crash
situation, could we add this to your patch?
* **migration and 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.
> ...so I'm not sure we especially need an "in scope" section.
ok, let's leave it behind.
