If the point of in-guest encryption is to protect against an unencrypted host or one that was captured before the guest was shutdown then IMO the benefits are very small and only realized if users meet a very strict and unrealistic requirements for how they use VMs. In normal usecases data from a running guest will leak unencrypted all over the host and stay there:
The performance penalty of running yet another layer of encryption (assuming the host has FDE) is too much given limited performance in a virtual environment as it is.
If the point of in-guest encryption is to protect a guest image at-rest sent over untrusted networks then this too is not a good idea. While data inside the image is encrypted and protected, image headers and the boot partition of the guest are not and could be maliciously modified in transit without the user noticing (unless they generate a hash the image to verify integrity). It would make more sense to just use GPG to encrypt the image file than continuously incurring the performance penalty of in-guest encryption for a rare usecase - transferring used image files over the internet.
Background⌠Most likely the recent criticism triggered this thread:
Previous stalled attempt:
My reply to that point:
Relevant quote:
[quote=âPatrick, post:4, topic:1251â]There has been an attempt to add encryption to Whonix images:
The master key would be known, but nevermind, thanks to cryptsetup-reencrypt this is not totally non-nonsensical.
If this is more than security theater is another question. The threat model here is, that the VM is shut down, while the host is powered up the moment the machine falls into the hand of an adversary. Virtualzer specific. The issue is, that the virtualizer might still have the key in RAM or written to the disk. Asking virtualizer vendors if this is at risk and implementing this feature is TODO.[/quote]
Added all of that to documentation:
http://docs.openstack.org/security-guide/content/data-privacy-concerns.html
Instance memory scrubbing
Specific to various hypervisors is the treatment of instance memory. This behavior is not defined in OpenStack Compute, although it is generally expected of hypervisors that they will make a best effort to scrub memory either upon deletion of an instance, upon creation of an instance, or both.
Xen explicitly assigns dedicated memory regions to instances and scrubs data upon the destruction of instances (or domains in Xen parlance). KVM depends more greatly on Linux page management; A complex set of rules related to KVM paging is defined in the KVM documentation.
It is important to note that use of the Xen memory balloon feature is likely to result in information disclosure. We strongly recommended to avoid use of this feature.
For these and other hypervisors, we recommend referring to hypervisor-specific documentation.
Linux memory allocation rules govern how KVM memory ballooning works and so it should not be a risk (its enabled by default BTW). More on that below.
Disabling swap would require to wipe (special secure delete) the existing swap. It might be the safest to never have used swap before.
Iâll add that disabling swap is not good for host stability (and still cannot prevent leaks caused by crashes)
With swap disabled, could it still happen, that the virtualizer writes [parts] of the VM's RAM's content to the disk? Virtualizer specific. TODO: Specifically ask virtualizer vendors about this.
Memory dumps caused by BSOD or kernel crashes can still leave unintenteded traces on the host even with in-guest encryption and following the (unrealistic) rules.
When a VM has been powered down, the RAM that previously contained the VM's encryption key might not have been wiped yet? Smilar to cold boot attacks, but in this case it might even be a "warm" attack, because under this threat model, the machine and RAM is still powered.
KVM guests are Linux processes and subject to Linux memory allocation rules. Its not possible that a VM process accesses the data of memory pages that belonged to another process.
Linux zeroes out (i.e. fills with zeros) all pages of memory not when they are released, but when they are given to another process. Thus, no process may obtain data excerpts from another process. However, the pages will retain their old contents until they are reused. I am not aware of any patch which does the zeroing upon page release
Theoretically, one could either build Whonix using '--target root' inside a VM. (Similar to physical isolation.) Secure VM settings would be missing. (Similar to Manually Create Whonix VM Settings.) Or add an encryption feature to grml-debootstrap and/or Whonix's build script. There was an attempt to do that, which stalled.
With the information researched, I think the only relevant situation Whonix should support encryption for is when doing a physical build and Whonix becomes the host.
1 Like
This is already documented in the physical isolation documentation (search for full disk encryption):
I'll add that disabling swap is not good for host stability (and still cannot prevent leaks caused by crashes)
But it reduces leaks, at least?
My experience is on the contrary. As soon as the host swaps, the system becomes super slow. Unusable for moments. Since I disabled swap (enough RAM), my experience has been improved.
Memory dumps caused by BSOD or kernel crashes can still leave unintenteded traces on the host even with in-guest encryption and following the (unrealistic) rules.
Good point. Please add this to the wiki.
KVM guests are Linux processes and subject to Linux memory allocation rules. Its not possible that a VM process accesses the data of memory pages that belonged to another process.
True. But besides the point. I mean something else...
âWhen a VM has been powered down, the RAM that previously contained the VMâs encryption key might not have been wiped yet? Smilar to cold boot attacks, but in this case it might even be a âwarmâ attack, because under this threat model, the machine and RAM is still powered.â â The threat model here is, that the attack examines the computer while itâs still powered on. In such as situation, the encryption key could still be in RAM, even if the VM was just powered down.
Linux zeroes out (i.e. fills with zeros) all pages of memory not when they are released, but when they are given to another process. Thus, no process may obtain data excerpts from another process. However, the pages will retain their old contents until they are reused. I am not aware of any patch which does the zeroing upon page release
That strengthens my point. As long as the RAM that was previously used by the VM was not assigned to another process, the adversary can try a root escalation + load kernel module, or local kernel exploit and cold boot attack to extract the VMs encryption key.
But it reduces leaks, at least?
Yes and no. Yes because nothing is written in no because without a place to offload less used pages, OOMKiller will have to kick in and start forcing processes to shutoff/crash uncleanly.
Trying to protect the guest from the host is ultimately futile.
"When a VM has been powered down, the RAM that previously contained the VM's encryption key might not have been wiped yet? Smilar to cold boot attacks, but in this case it might even be a "warm" attack, because under this threat model, the machine and RAM is still powered." -> The threat model here is, that the attack examines the computer while it's still powered on. In such as situation, the encryption key could still be in RAM, even if the VM was just powered down.
Ah OK then warm attacks are easy feasible. In this situation the contents of the VMâs RAM would still be available until the pages are requested by another process, which would then zero them out first (as confirmed by the post describing the behavior of memory allocation).
That strengthens my point. As long as the RAM that was previously used by the VM was not assigned to another process, the adversary can try a root escalation + load kernel module, or local kernel exploit and cold boot attack to extract the VMs encryption key.
On the host yes. If you mean something else please explain.
Yes and no. Yes because nothing is written in no because without a place to offload less used pages, OOMKiller will have to kick in and start forcing processes to shutoff/crash uncleanly.[/quote]
Where is the ânoâ? Killing processes uncleanly does not produce leaks, no? And this is something which can be prevented by having an eye on free RAM. Not hard (pre-supposes one can buy high end hardware with abundance of RAM). Note: this is all in context of advanced security guide. So having an eye on available RAM is something that can be expected. And when messed up, there would still be no leak. âJustâ a crash.
Trying to protect the guest from the host is ultimately futile.
Yes, but preventing something from images (that are maybe on an encrypted external disk) leaking onto the host's disk - such as swap - is still worthwhile, no?
Ah OK then warm attacks are easy feasible. In this situation the contents of the VM's RAM would still be available until the pages are requested by another process, which would then zero them out first (as confirmed by the post describing the behavior of memory allocation).
Yes.
[quote]That strengthens my point. As long as the RAM that was previously used by the VM was not assigned to another process, the adversary can try a root escalation + load kernel module, or local kernel exploit and cold boot attack to extract the VMs encryption key.[/quote]
On the host yes. If you mean something else please explain.
Thatâs what I meant.
Considering the warm boot leaks and the very limiting operational circumstances Iâm just not seeing in-guest encryption protecting much.
The only ones protected are those who:
-
never suspended or hibernated their host when running a guest.
-
never saved a guest vm.
-
never enabled swap when a guest was running.
-
never had the host crash on them when running a guest (if youâre on Windows good luck).
-
booted the host from a cold state and never ran your guest during the entire session - during which the machine was stolen.
That's what I meant.
If they are stealthily living on your host then its game over on so many levels. In-guest encryption wonât help there either.
Donât misunderstand my intentions here. I am not unclear if I am starting to work on this anytime in this life. This is too much work. Would take me too long. What I hope to gain from this discussion is a clear dump of the current state of affairs documented in the wiki. This is useful for many purposes.
- having those issues eventually be fixed at some point [ex: kernel option patch to wipe RAM after VM shutdown] (less likely)
- strengthen security thinking, someone going through this thought experiment gains better understanding of threat models and many factors that are at work here (more likely)
- having a good answer, next time this topic comes up (every now and then)
- having documentation ready, in case this feature gets contributed
* never suspended or hibernated their host when running a guest.
* never saved a guest vm.
* never enabled swap when a guest was running.
Or somehow figured out how to securely wipe this?
* never had the host crash on them when running a guest (if you're on Windows good luck).
Can't these crash dumps be disabled or are those even enabled by default?
* booted the host from a cold state and never ran your guest during the entire session - during which the machine was stolen.
Yes. Plus a small exception. Maybe they were lucky and the RAM was reassigned to some other process, so the encryption key of the now powered down VM has been overwritten. And perhaps that overwriting can be made more likely?
[quote]That's what I meant.[/quote]
If they are stealthily living on your host then its game over on so many levels. In-guest encryption wonât help there either.
True. But I think we already agreed on this.
âAs long as the RAM that was previously used by the VM was not assigned to another process, the adversary can try a root escalation + load kernel module, or local kernel exploit and cold boot attack to extract the VMs encryption key.â â On the host. After getting physical access. [The threat model here.]
Actually, what I am saying, this strengthens your position, that image encryption doesnât bring huge benefits.
Don't misunderstand my intentions here. I am not unclear if I am starting to work on this anytime in this life. This is too much work. Would take me too long. What I hope to gain from this discussion is a clear dump of the current state of affairs documented in the wiki. This is useful for many purposes.
OK. For the record, I am advocating that we simply drop the parts of this feature we already have (I realize this too can take a lot of time) instead of extending it and also developing all kinds of ways on the host to deal with the shortcomings - and some of the OS changes needed are way beyond our project and sometimes even that is not possible if we are talking about proprietary systems. On any OS today you can either protect everything by the FDE layer or nothing at all. They are not designed for the kind of per application encryption that is being attempted here.
I am advocating that we simply drop the parts of this feature we already have
Now I am confused? Which parts do we have? None at all?
Now I am confused? Which parts do we have? None at all?
I thought Whonix encrypts its swap partition with a randomly generated key on boot, or something similarâŚ
If none of that is going on lets keep it that way because now we know why in-guest encryption doesnât make sense.
Ah, you mean GitHub - Kicksecure/swap-file-creator: Adds encrypted swap file to the system - for better protection of locally stored data and to aid environments with low RAM. https://www.kicksecure.com/wiki/swap-file-creator. That package is useful for:
- someone implementing image encryption
- swap file creation is easier and more robust than trying to ship Whonix images with a swap partition
- useful for physical isolation
- hopefully one day landing in Debianâs repository. I find swap partitions non-ideal. Those complicate the disk partition layout. Risk unencrypted swap on host.
- using https://github.com/Whonix/swappiness-lowest anyhow
- having unified configs for images and physical isolation, no delta âdisable encryption in VMs, but have it enabled on hardwareâ
Itâs easiest to keep it as is.
It probably needs some adjustments to the threat model section to explain its new benefits. Also libvirt introduced LUKS encryption for disk image volumes. I still havenât played around with that yet. Is this worth adding to the wiki too or is t too specific?
I need to fact check a contradicting bit of info - whether Linux memory pages are zeroed immediately after the process exits or only upon request by another process? The latter is preferred of course since secret data from a process doesnât hang around for long.
@Algernon @Hexagon do you know anything about this?
UPDATE:
Found new citations
does linux zero memory released by applications - Super User and security - Linux overwriting RAM with zeroes on free() - Ask Ubuntu agree with a source we already have (Is there any Linux distro or kernel patch that wipes a process memory space after the process exits? - Information Security Stack Exchange).
CONCLUSION:
Linux memory pages are zeroed only upon request by another process
As mentioned in the last answer in the last source PaX provided the feature to wipe RAM data on free:
http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory
While there is an upstream implementation of CONFIG_PAX_MEMORY_SANITIZE being added, it has some expensive performance impact.
Will add to the wiki later including note on luks libvirt and reencrypt.
The main point here is that powering down a swapless machine after use eliminates this problem.
There is cryptsetup-reencrypt. Meaning: we could ship encrypted images. The master key and the password (perhaps empty if possible) would be known to the public. Users could use cryptsetup-reencrypt to fix the master key and password, i.e. to make the encryption effective. At least as far as I understand. This would solve a redistribution issue (images downloadable by the public) that I mentioned earlier somewhere. (I thought, if we ship an encrypted image, the master key is known, users could change their password all they want and still be insecure. Actually thatâs a non-issue.)
Worth adding since itâs the advanced security guide anything goes. Worth getting this straight also since it influences possible Whonix Live / amnesic in some forms.
While it seems obvious it might be worth noting in the wiki that you canât use sparse images if you want to initialize the disk with random data (which is recommended to prevent disclosure of usage patterns on the encrypted drive).