Whonix ™ Live Mode
|About this Whonix Live Page|
- 1 Introduction
- 2 Warning
- 3 Anti-Forensics Precautions
- 4 Live-mode Configuration
- 5 Debugging/Errors
- 6 Miscellaneous
- 7 Footnotes
Users can optionally run Whonix ™ as a live system.  Booting into live mode will make all writes go to RAM instead of the hard disk. Everything that is created / changed / downloaded in the VM during that session will not persist after shutdown. This also holds true for malicious changes made by malware, so long as it did not break out of the virtual machine.
grub-livewill create a new boot menu entry which the user has to select manually but it is the more failsafe and hence the recommended option.
ro-mode-initthe boot menu will stay the same and the system will automatically boot into live mode when it detects a read-only disk otherwise it boots normally into persistent mode. The advantage of using this approach is that malware running in a VM can’t silently change settings to leave persistent traces.
Live mode is not amnesic by itself and needs extra steps to be taken on the host to be effective. Also, memory forensics has not been taken into account! The primary objective is preventing malware from gaining persistence and having an unchanged system after each reboot.
Whonix-Gateway ™: If live mode is used with Whonix-Gateway ™, regularly booting into persistent mode is important to keep Tor's normal guard rotation schedule.
When Whonix ™ is run as a live system, all changes are written to RAM by default. However, it is possible for this design to be bypassed if swap files, core dumps and other relevant configurations are in effect. Fortunately, most of these can be disabled.    
To stymie disk forensics, ideally full disk encryption should be applied on the host and the computer should be powered off when not in use. Alternatively, the whole host OS could be run from RAM, or a live system run on the host with all writes going to RAM. The latter method also requires a correctly implemented write protection switch.
To make memory forensics harder, the machine should either be removed from any power source (by pulling the plug / removing the battery) and/or the memory should be wiped upon shutdown.
Since live mode makes each write go to RAM, the user might want to increase the memory assigned to the VM to improve performance; for example, if large files are regularly downloaded.
Whonix ™ 15 includes grub-live by default. When using this feature in Whonix ™ VMs, some precautions need to be taken even on trusted systems like GNU/Linux hosts to prevent leaving traces (proprietary OSs are a lost cause). At the moment, the only advantage of doing this over running grub-live on the host, is to achieve selective amnesia for some VMs while others remain persistent. As grub-live development continues to advance allowing for selective exemption of host directories, this may not be necessary in the future. This section is a work in progress and not exhaustive.
Disabling swap for entire system
Turning off for the whole system may cause a system instability/crashes if the RAM hard limit is hit. However the ample RAM in new systems makes it unlikely and it is worth the tradeoff. Disabling swapalso disables hibernation functionality.
On the host.
This command will disable swap and delete the file during the life of this session:
sudo swapoff -a
To disable swap in a persistent way edit the
fstab file and comment out the line with the swap partition with a
sudo nano /etc/fstab
Save and reboot.
Confirm it is off by checking the
free command. The swap line should show zeros:
TODO: existing swap partition should get securely wiped since sensitive information such as encryption keys might have already leaked there
Disabling swapping selectively for KVM VMs
This option is not without disadvantages however and can be abused by malicious guests DoSing the host through RAM exhaustion. 
vm.swappiness = 0 does not completely prevent swapping. 
grub-live on Whonix-Gateway ™
It is recommended users run the live package on Whonix-Gateway ™ too after initial Tor start when a guard has been set. This should eliminate any Tor related cached data like DNS requests that could leave traces about web activity. However be warned that it may make your Tor behavior distinguishable from regular Tor users when it comes to redownloading consensus files more frequently or when switching to a new guard after some months have passed. 
Disabling program crash dumps
Besides swap there is the problem of disabling process memory dumping to disk.
A user has to go out of their way to enable kernel memory dumps which isn't done by default, with kdump-tools on Debian.
The default core dump file size is 0 on Debian Linux:
ulimit -c 0
It is enforced for systemd-coredump too.
Can be verified with lack of core files in
/var/lib/systemd/coredump when an intentional crash is induced (
/var/crash doesn't exist on Debian but may be available on other Linux distributions).
Disable setuid processes dumping their memory
Processes with elevated permissions (or the setuid bit), might be still able to perform a core dump, depending on your other settings. As these processes usually have more access, they might contain more sensitive data segments in memory. So time to change this as well. The behavior can be altered with a sysctl key, or directly via the /proc file system. For permanent settings, the sysctl command and configuration is typically used. A setting is called a ‘key’, which has a related value attached to it (also known as a key-value pair).
To disable program with the setuid bit to dump, set the fs.suid_dumpable to zero:
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
Reload the sysctl configuration with the -p flag to activate any changes you made.
Following reboot, a second boot entry called "Whonix ™ Live-mode" will be visible. Simply press
Enter to boot the live system and use it as normal.
To increase security, the VM disks can be set to read-only. Otherwise, malware running as root in the VM could theoretically mount the image read-write and gain persistence in this way. To do so, power off the machine and set the hard disk to read-only in the virt-manager GUI before booting into live mode. To boot into normal mode again, simply revert this change and choose the normal boot option in the GRUB menu.
Virtualbox and KVM:
An inconsistent filesystem will likely result in errors during live-boot. For instance, inconsistencies can arise when the VM is killed instead of performing a normal shutdown in persistent mode. Therefore, to make sure it is consistent, run
fsck in persistent mode. Debian automatically does this during boot. VMs running in live mode can be killed without problems.
In the case of non-
fsck related errors using
ro-mode-init (like dropping to an initramfs shell), add the following to the kernel command line/GRUB menu for easier debugging:
In the future, running Whonix ™ from a Live CD or DVD might be supported. Check this wiki entry at a later date.
To learn more about live mode, refer to the Live-mode forum discussion.
- Since Whonix ™ 14.
- Is there a Whonix ™ Amnesic Feature / Live CD / Live DVD? What about Forensics?
- Whonix ™ is not Amnesic
- Encrypted Guest Images - Other Security Considerations
- Core Dumps
- Tails documentation comments that host swapping may be the biggest threat to anti-forensics on Linux when running in a VM https://tails.boum.org/doc/advanced_topics/virtualization/index.en.html#security
- Linux does use swapping despite having apparent "free" memory. The kernel tends to swap out long-inactive and memory-consuming processes. This frees up RAM for caches, thus improves responsiveness.
- When set and supported by the hypervisor, memory pages belonging to the domain will be locked in host's memory and the host will not be allowed to swap them out, which might be required for some workloads such as real-time. For QEMU/KVM guests, the memory used by the QEMU process itself will be locked too: unlike guest memory, this is an amount libvirt has no way of figuring out in advance, so it has to remove the limit on locked memory altogether. Thus, enabling this option opens up to a potential security risk: the host will be unable to reclaim the locked memory back from the guest when it's running out of memory, which means a malicious guest allocating large amounts of locked memory could cause a denial-of-service attack on the host. Because of this, using this option is discouraged unless your workload demands it; even then, it's highly recommended to set a `hard_limit` (see [memory tuning](https://libvirt.org/formatdomain.html#elementsMemoryTuning)) on memory allocation suitable for the specific environment at the same time to mitigate the risks described above.
No user support in comments. See Support.
Comments will be deleted after some time. Specifically after comments have been addressed in form of wiki enhancements. See Wiki Comments Policy.
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation.
Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)