Neutralizing the security risk of QEMU Guest Agent without removing it

forest

@vicaya said: Host can easily dump guest memory and use findaes to get your DEKs directly without using LUKS passphrases. They only need to do that once and then decrypt the disks offline at their leisure. Nested LUKS would require coordinated effort from different vendors, assuming the correct setup.

Well yes, but using multiple FDE utilities won't make that any harder. In fact, utilities that scan memory for AES keys don't actually look for the DEK, they look for the round keys which always have a certain relation to each other. So no matter what vendor you use, they'll get the keys easily. Trying to hide them would be security by obscurity.

@vicaya said: Not if you use the official (non-cloud-init) version of the iso or install from netboot. The guest agent is not installed by default, e.g., ubuntu server minimal iso.

I mean qemu-ga installs by default, including on Debian netboot, when virtualization is detected.

vicaya

@forest said:

@vicaya said: Host can easily dump guest memory and use findaes to get your DEKs directly without using LUKS passphrases. They only need to do that once and then decrypt the disks offline at their leisure. Nested LUKS would require coordinated effort from different vendors, assuming the correct setup.

Well yes, but using multiple FDE utilities won't make that any harder. In fact, utilities that scan memory for AES keys don't actually look for the DEK, they look for the round keys which always have a certain relation to each other. So no matter what vendor you use, they'll get the keys easily. Trying to hide them would be security by obscurity.

[D1: encrypted for vendor 1 [D2: encrypted for vendor 2] - nbd-server for D2] -> [nbd-client to mount D2 on vendor 2, optionally with dm-cache for performance]

On vendor 1, D2 is encrypted, no D2 key in memory. On vendor 2, no D1 key in memory. These vendors need to collude to decrypt disk images saved on vendor 1 offline, which is enough thwart curious admins of either vendor.

@vicaya said: Not if you use the official (non-cloud-init) version of the iso or install from netboot. The guest agent is not installed by default, e.g., ubuntu server minimal iso.

I mean qemu-ga installs by default, including on Debian netboot, when virtualization is detected.

This is a debian quirk. Ubuntu server minimal doesn't do that.

forest

@vicaya said: On vendor 1, D2 is encrypted, no D2 key in memory. On vendor 2, no D1 key in memory. These vendors need to collude to decrypt disk images saved on vendor 1 offline, which is enough thwart curious admins of either vendor.

Oh, by vendor you mean different hosts? I thought you meant different encryption software. What's to stop someone who hijacks the VPS from accessing data on the other VPS? Without a proper TEE, the host can do whatever you can.

vicaya

@forest said:

@vicaya said: On vendor 1, D2 is encrypted, no D2 key in memory. On vendor 2, no D1 key in memory. These vendors need to collude to decrypt disk images saved on vendor 1 offline, which is enough thwart curious admins of either vendor.

Oh, by vendor you mean different hosts? I thought you meant different encryption software. What's to stop someone who hijacks the VPS from accessing data on the other VPS? Without a proper TEE, the host can do whatever you can.

Different hosts is not enough, they need to belong to different vendors for admin isolation. A persistent vendor 2 admin cannot get into a properly locked down live instance "easily" vs simply dump the memory and decrypt offline if you don't use this method. Of course, we all know properly implemented FDE (with attested key release) in TEE is a lot more secure. The nested encryption strategy works for 2+ TEE vendors for even better security.

Protocol903

This is amazing. Perfect thing that I've been looking for.

However, i'm stuck between if I should allow provider to change password or if I shouldn't. What if I forget password? Or lock myself out cuz fail2ban?

Mainfrezzer

@Protocol903 said:
This is amazing. Perfect thing that I've been looking for.

However, i'm stuck between if I should allow provider to change password or if I shouldn't. What if I forget password? Or lock myself out cuz fail2ban?

Don't use passwords and how badly do you need to fumble that you manage to block all ips with fail2ban? I mean, I get it, I do ban myself occasionally for tests too but either that's gonna expire or I just use mobile or one of my vpns/isps

zed

@Protocol903 said:
This is amazing. Perfect thing that I've been looking for.

However, i'm stuck between if I should allow provider to change password or if I shouldn't. What if I forget password? Or lock myself out cuz fail2ban?

we can probably find you an online basic system administration course if it comes to that.

snowman11

If you are hosting something sensitive then you dont host it on a VM. Its as simple as that in my eyes

Nekopara

thanks, applied this to some of my vps

JohnFilch123

@snowman11 said:
If you are hosting something sensitive then you dont host it on a VM. Its as simple as that in my eyes

Where do you host it then?