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. > >> > With TLS we lack fine grained authentication in common setups >> > today that rely on x509 certs configured per-host, not per-QEMU. >> > >> > In current libvirt we're introducing oout of the box support for >> > TLS PSK, which means live migration sessions will be tied to >> > individual matched (src,dst) QEMU pairs, so even if tenant A is >> > compromised they would be able to do a TLS handshake for tenant >> > B's dst QEMU. >> > >> >> ITYM "wouldn't be able". > > Yes. > >> > I'd like app mgmt apps to switch to PSK instad of x509 for >> > live migration, but that'll take along time. >> > >> >> Is TLS PSK a reasonable setup to expect and to include in this policy? > > We should probably have a standalone doc for migraton detailing > the recommended configuration scenarios, we could then link to > from this doc if needed. > > >> > WIth this it seems like the only 2 scenarios where a migration security >> > flaw can be issued are: >> > >> > * Something goes wrong before/during the TLS handshake >> > * A bug in source QEMU, somehow allows a guest OS user >> > to set magic device data that turns into an exploitable >> > VM state record. >> > >> >> We don't need a bug in source QEMU, the magic data could be within >> accepted parameters. > > I guess there could be a bug in the dest QEMU that trips up over > otherwise valid vmstate data. Dn't recall seeing an example of it > but never say never. > > > With regards, > Daniel
