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. > 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". Anything not out of scope then gets triage to decide whether it is in scope or not.... > IN SCOPE: > > 1) Privilege escalation from the guest operating system into the > destination QEMU process or host. > > 2) Tampering or exfiltration of migration stream data by a third party > at a lower privilege level than either QEMU processes involved in the > migration. > > 3) Termination of the source QEMU process by source virtual machine > guest userspace, including by forcing host OS resource constraints to > be reached. > > 4) Other tampering or exfiltration of data from the source QEMU process > if reached from migration code or migration stream manipulation. > > 5) Causing source QEMU process to enter a state from which migration is > not possible permanently. ...so I'm not sure we especially need an "in scope" section. 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 :|
