On Mon, Jul 20, 2026 at 12:23:33PM -0300, Fabiano Rosas wrote: > Daniel P. Berrangé <[email protected]> writes: > > >> >> 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. > >> > > >> > This is the tricky assumption. > >> > > >> > Cnsider source host as 2 QEMU processes, one of tenant A and > >> > one for tenant B. > >> > > >> > If tenant A compromises their QEMU, and can wait until a live > >> > migration for tenant B is initiating, potentially tenant A can > >> > connect to a dest QEMU for tenant B. I would consider that to > >> > be gaining privileges. > >> > > >> > >> I thought of that, but I can't understand how "dest QEMU for tenant B" > >> isn't just "dest QEMU for tenant A that has now took over". If none of > >> the stream from source B is reaching dest B, then that's harmless. > > > > Two VMs configured with identical virtual hardware should have > > the same vmstate structure, and so be compatible from the > > POV of live migration flow. They can none the less have different > > backend connections. So if tenant A can connect to a incoming > > QEMU from tenant B, the live migration can probably succeed, > > thus giving tenant A a working VM but with the HDD now backed > > by data belonging to tenant B. > > > > Ok, I haven't thought about the storage aspect. In the scenario you > describe, there's nothing the migration code can currently do to avoid > such an exploit. The "migration process" seen as a larger thing is > vulnerable and there's currently no code in QEMU whether broken or > behaving properly that would stop this attack. We're kind of back to > what Peter said that compromised source is game over. Unless I'm missing > some mechanism.
IMHO the only sure fire way to stop this kind of attack is fine grained access control over migration, to prove the incoming client connection corresponds to specifically the source QEMU we are expecting. And the only way we have todo that is * Use a seperate x509 certificate for every VM. This is a mgmt nightmare so not viable IMHO * Use TLS-PSK instead of x509 certificates. Effectively this is akin to single-use certificates generated on the fly by the mgmt app that owns QEMU (libvirt). IOW, the situation today is that every deployment of QEMU is pretty much assuming that the source QEMU is not compromised, as no one does either of those approaches (yet). 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 :|
