Anti-forensics Precautions when using Kicksecure ™ VMs in Live Mode
Kicksecure ™ users have the option of booting into VM live mode. When using this feature in Kicksecure ™ VM, precautions should still be taken on trusted systems (like GNU/Linux hosts) to prevent leaving traces -- proprietary operating systems such as Windows and macOS are a lost cause.
At the moment there is only one advantage of this configuration compared to using Host Live Mode is -- achieving selective amnesia for some virtual machines (VM) while others remain persistent. This section is a work in progress and not exhaustive.
When Kicksecure ™ VM are run as a live system, all changes are written to non-persistent memory (RAM) by default. However, it is possible for this design to be bypassed by malware, swap files, core dumps and other relevant configurations that are in effect. Fortunately, most of these can be disabled.    
To prevent malware from remounting the hard drive as read-write it is highly recommended to use read-only hard drive mode. This raises the bar because malware would need to break out of the VM to gain persistence. In order to stymie disk forensics, it is suggested to apply full disk encryption on the host and the computer should be powered off when not in use.
Alternatively or in addition to full disk encryption, the entire host operating system could be run in live mode. This is called Host Live Mode. In this configuration, all writes are redirected to the non-persistent memory (RAM). Running the host operating system in live mode would additionally benefit from a correctly implemented write protection switch; this is not required but highly recommended.
To make memory forensics harder, make sure you shutdown your computer normally  and then remove the machine from any power source by pulling the power plug. In the case of notebooks, the battery should be removed.  See also Cold Boot Attack Defense.
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
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 VM
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. 
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: 
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:
Reload the sysctl configuration with the -p flag to activate any changes you made.
- Is there a Kicksecure ™ Amnesic Feature / Live CD / Live DVD? What about Forensics?
- Kicksecure ™ is not Amnesic
- Encrypted Guest Images: Other Security Considerations
- Core Dumps
so the Linux kernel's memory erasing features (
init_on_free) and/or your firmware reset attack mitigation can kick in
- And/or the memory should be wiped upon shutdown. This is a theoretical mechanism at present because it is undocumented. https://forums.whonix.org/t/is-ram-wipe-possible-inside-whonix/5596
- 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.