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,  but this is only available in Non-Qubes-Whonix. 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-live: a new boot menu entry is created which must be selected manually, but it is a better failsafe and hence the recommended option.
ro-mode-init: the boot menu stays the same and the system automatically boots 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 cannot silently change settings to leave persistent traces.
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.
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 OSes are a lost cause). At the moment there is only one advantage of this configuration compared to running grub-live on the host -- achieving selective amnesia for some VMs while others remain persistent. This may not be necessary in the future if grub-live development continues to advance and it allows for selective exemption of host directories. This section is a work in progress and not exhaustive.
Disabling swap for an entire system
Turning off swap for the whole system may cause system instability or crashes if the RAM hard limit is reached. However the ample RAM in new systems makes this unlikely and it is worth the tradeoff. Disabling swap also disables the hibernation functionality.
On the host
The following 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 (using
#) with the swap partition.
sudo nano /etc/fstab
Save and reboot.
Confirm it is off by checking the
free command. The swap line should show zeros.
TODO: the existing swap partition should be securely wiped since sensitive information like encryption keys might have already leaked there.
Disabling swapping selectively for KVM VMs
This option is not without disadvantages - it 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 to also run the live package on Whonix-Gateway ™ after the 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:
- Consensus files: These files will be (re-)downloaded more frequently.
- Tor guards: 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 must go out of their way to enable kernel memory dumps since it is not enabled by default; kdump-tools is utilized in Debian. 
The default core dump file size is
0 on Debian Linux: 
ulimit -c 0
This setting is enforced for systemd-coredump too and can be verified by inspecting the lack of core files in
/var/lib/systemd/coredump when an intentional crash is induced (
/var/crash does not exist in Debian but it may be available in other Linux distributions). 
Disable setuid processes dumping their memory
Processes with elevated permissions (or the setuid bit) might still be able to perform a core dump, depending on your other settings. These processes usually have more access and might contain more sensitive data segments in memory, so they should be changed 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 programs 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.
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 ensure 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 notes that host swapping may be the biggest threat to anti-forensics on Linux when running in a VM; see Security Considerations.
- Linux also uses swapping despite having apparent "free" memory. The kernel tends to swap out long-inactive and memory-consuming processes. This frees up RAM for caches and therefore improves responsiveness.
- When set and supported by the hypervisor, memory pages belonging to the domain will be locked in the 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 is running out of memory. This means a malicious guest allocating large amounts of locked memory could cause a denial-of-service attack on the host. Due to the risk, this option is discouraged unless your workload demands it. Even then, to mitigate these risks it is strongly recommended to set a `hard_limit` (see memory tuning) on memory allocation suitable for the specific environment at the same time.
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?)