Re: reg: Question on LUKS device's content exposure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux