On 13 Oct 2021 08:41 +0000, from samsapi01@xxxxxxxxxxxxx (sami0l): > Suppose my VPS provider wants to view contents of > /mnt/sdb1_crypt_files, will they be able to mount the device file > /dev/sda to view the contents at /dev/mapper/sdb1_crypt or > /mnt/sdb1_crypt_files? Meaning, since /dev/mapper/sdb1_crypt, > /dev/sdb1 or /mnt/sdb1_crypt_files are *within* the main or root > /dev/sda will they get access to the files which is within the LUKS > device (and decrypted at /dev/mapper/sdb1_crypt) too? Anyone who is in control of the hypervisor will be able to inspect the VM's portion of the host's RAM, and extract from it anything they wish, including cryptographic keys or other relevant material (or just copy it wholesale). They can also freeze the VM while doing so, ensuring a consistent view of its state. They can also snapshot any stable storage, to be transferred to another system and/or examined at their leisure. They can also take all the data available to them and spin up a brand new, identical VM that, to the software running within it, unless it goes out of the way to the outside world to look, will look pretty much like nothing ever happened; and _after_ the fact, it's too late. Basically, realistically, nothing running _inside_ the VM can do very much about that. At most, it can detect that some operations took longer than normal to complete. I believe Intel had a technology at least quite far along which aimed to mitigate this exact threat, but that still depends to some degree on you trusting the provider to not lie about offering (and instead emulating) it. And of course, there's the age-old issue of how the VM (the VPS) obtains the passphrase to unlock the LUKS container. If provided interactively during the boot process, what's to say that the provider's remote management functionality doesn't log every keypress? If you connect after boot and unlock the container, then how do you know for a fact that the kernel's network drivers or the SSH daemon haven't been tampered with? _It's someone else's computer._ You're along for the ride. You can put speedbumps on the road, but that isn't going to stop someone with a helicopter from flying over them. If in your threat model this is a problem, then a simple, at least partial, solution is to rent a whole lockable rack, install your own server hardware, and put some kind of tamper-detection system in place to wipe relevant memory and force-shutdown the server immediately if the rack is opened or otherwise tampered with without proper prior authorization steps. But that, of course, will be "a bit" more expensive than most VPS offerings, to the tune of two to three orders of magnitude (or thereabouts). Another order of magnitude up in cost gets you your own moderately fast redundant Internet uplink and a server room of your own where you can install whatever alarm systems you fancy. Make sure the racks are locked, set the alarm system up such that it cuts power through the PDUs when it goes off, and you've made the attack somewhat more difficult. But not impossible. -- Michael Kjörling • https://michael.kjorling.se • michael@xxxxxxxxxxx “Remember when, on the Internet, nobody cared that you were a dog?” _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
