I have openSUSE Tumbleweed running in a VM on VMware vSphere/ESXi 6.7 hosted by a commercial provider. There are two virtual discs, one for / and swap and one for /home. As home directories will contain private data, I thought about encryption of /home directories e.g. by disc encryption to prevent the provider from having access to (or the possibility to access) my private data. Are there other methods to encrypt /home than using disc encryption? I read about encryptfs, but also read that this is not maintained for openSUSE anymore.
Moreover, I couldn’t find any details whether /home encryption makes sense in a VM environment or not. With disc encryption I need to type in the password as I start/restart the VM to unlock the disc containing /home. How does this unlocked disc actually looks to the outside world i.e. the commercial provider of my VM? Might the provider read the data on the unlocked disc containing /home as long as the VM runs or is it encrypted on the flight, so that the VM provider can’t access the data?
Firstly, I’ll note that I am not using “vmware” so I have no experience with that. I do virtualization with KVM.
As far as I know, “ecryptfs” is still well supported. OpenSUSE did drop support for encrypted home directories, but that was using a loop mounted LUKS container. Encrypted home directories can still work with “ecryptfs”.
Personally, I use an encrypted LVM on my main system and in some (but not all) virtual machines. However, as you surmised, that requires a password when booting.
Before I retired, I was using “ecryptfs” for an encrypted home directory on my work machine. And I also used encrypted swap, with a random encryption key on that system. The benefit is that the system can be booted unattended (no key needed). You provide the encryption key when you login. The encryption key for swap comes from “/dev/urandom” so you never need to provide that – but you cannot hibernate since resume from hibernation would require that key which you don’t know.
The downside of “ecryptfs” is that the “systemd” people broke it. When I logout, my “ecryptfs” directory stays mounted and thus is visible to someone with root access. My work-around for this is to manually unmount the “ecryptfs” directory just after or during logout.
I’m using KDE, so I do that via a script in “.config/plasma-workspace/shutdown/”. Okay, that’s not really doing it manually.
cat .config/plasma-workspace/shutdown/ecrypt-off.sh
:
cd /
ecryptfs-umount-private
ecryptfs-umount-private
Note that I use that with an “ecryptfs” private directory. I have not tested that with using “ecryptfs” for encryption of the full home directory, where it might fail if any part of KDE is still using that home directory.
Thanks for your prompt reply on ecryptfs. From my perspective it would be alright to have a mounted ecryptfs directory after logout, as long as I can ensure that there is nobody else with root access on my openSUSE VM. However, I suspect that the people providing the environment for my VM can have a look in the virtual disks. How does your private folder look like from this “outside world” if you are logged in and your ecryptfs private folder is mounted?
If you are just looking at disks, then I don’t think you can see it. The unencrypted data is sitting in memory, and mounting the directory just means making that memory image available as if it were disk space.
Decrypt is done on the fly through reading/writing files the image on disk is always encrypted. so someone looking at the raw files only sees encrypted data.
The general rule of thumb is that encrypting files (and directories, partitions and full disk encryption) only protects data “at rest.”
For the encrypted data to be used, it has to be decrypted so exposes the data to anyone who has physical access to the machine… There’s no likely way around that although you can put measures in place to “keep honest people hones” but could be overcome.
Securing mounted and running data usually involves different measures, but can’t rely on file encryption.
Like anything else about computer security,
You have to clearly define what you want to protect against, and only after that evaluate your options.
Ordinary methods supported by openSUSE can be considered, too.
Of course,
You will be required to provide credentials when you boot if you implement some kind of low level encryption that’s not integrated with OS security… It takes a long time for an OS to boot and the file system must be mounted before an OS is fully loaded so many people prefer not to use disk encryption that’s integrated with OS security. Better to do things like have a signed legal agreement specifying permitted access and penalties for violations, a combination of system and network based security, increased logging levels, etc.
If it’s important to you,
There’s a recent discussion about some recently discovered vulnerabilities using TPM based encryption (encryption keys stored in hardware)., so the current recommendation if you want to avoid those vulnerabilities is to use encryption solutions that generate different keys and store elsewhere (typically on disk).