Question about privacy of virtualization? #7
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
hey y'all, I'm really excited about this project!
I have a question, and apologies if this is the wrong place to ask it, but didn't see a forum yet.
I was wondering, is the creator of the virtual machines, the root of the host machine, able to ssh into the VMs they create if they wanted to? or to change the password of the VM if they wanted to to then get access?
or even if this is the default, was wondering if there would be anyway to achieve a situation where the admin of the "host" server couldn't even be able to log into the VMs running on it if they wanted to even with root privileges on the host machine?
in particular, I was thinking about how I'd like to be able to create some yunohost instances for friends, but in VMs, in such a way that it was also private to me.
I don't know a ton about VMs, so I might not be wording this question properly, but hopefully makes sense. Thanks for any input,
@notplants
Hey @notplants, didn't get notified about this at the time, sorry! As a very late answer, I'm not aware of a way of preventing this access: even if the VM was using encrypted storage (and kinda-inconveniently requiring a password to be entered every reboot), a nefarious server operator could spy on the password being entered, through various means.
CC @forest @decentral1se in case you know of anything which could help?
Computer science wise I think this is still an open question, whether this is possible at a technical level or not. (VM guests who don't have to trust the VM host)
Last time I was paying attention to this, like 2017 or so, I believe the record was that they could do it, and they could even prove that it worked using math or something, which was a breakthrough at the time. But, it ran like 1 million times slower than a normal computer.
In terms of practical purposes, I think that the full disk encryption option offers a reasonable level of surveillance-resistance... As long as you're willing to sacrifice ease-of-use and availability.
The only issue is, like 3wc said, if the VM ever reboots, then the user has to manually unlock it.... every single time 😫
Right, when it comes down to brass tacks, what they could do is stop the VM, go in and edit the initramfs or partition or whatever it boots into before it unlocks the LUKS (Linux Unified Key Setup) full disk encryption. They could replace parts of that system with backdoored ones that leak the encryption key for example.
They might also just be able to pause the VM, take a RAM snapshot, and extract the key that way.
Keep in mind tho, setting up LUKS like this on a server is hard enough, being able to attack such a setup successfully without breaking it is a whole nother story. Its a 10 on technical difficulty scale, thats why I was saying that it provides a reasonable level of protection as long as your users are patient and technical enough to wade thru the remote LUKS unlock swamp every single time.
IMO Its important to distinguish between computation and storage.
Un-trusted storage already exists, you just use end-to-end encryption on the trusted computer and then send the encrypted blocks or blobs to the un-trusted storage system.
But un-trusted compute as a service IMO is a no-go / non-goal.
Tysm for comprehensive thoughts @forest 🙏
Yeah agreed it wouldn't be easy. I think the "extract encryption keys from RAM" attack is probably easier, but still hard.
love when a thread gets a really interesting set of responses three years later <3
(not joking)