Qubes OS 100% in RAM tmpfs anti-forensic amnesic script dom0: Allows restoration

Automates the configuration to run the Qubes dom0 100% in RAM and use appvms and templates in varlibpool within dom0, remaining 100% amnesic in an anti-forensic condition like Tails OS! Allows restoration to the original Qubes!

How to Install

Download from github: GitHub - leandroibov/qubes-os-live-in-ram-tmpfs-anti-forensic: Automates the configuration to run the Qubes dom0 100% in RAM and use appvms and templates in varlibpool within dom0, remaining 100% amnesic in an anti-forensic condition like Tails OS! Allows restoration to the original Qubes!

For Qubes 4.2, use 4.2.ephemeral.sh or 4.2.ephemeral_old.sh (obsolete version, but it works and has been tested for much longer).
For Qubes 4.3, use 4.3.ephemeral.sh.
Do not use anything different or you may damage your Qubes OS!

Example with 4.3.ephemeral.sh

Using the appvms called vault and the user user:
Copy the script 4.3.ephemeral.sh to the appvm vault for user user in /home/user/ so it will be /home/user/4.3.ephemeral.sh.
Open the terminal in dom0 and type:
qvm-run --pass-io vault ‘cat “/home/user/4.3.ephemeral.sh”’ > /home/user/4.3.ephemeral.sh
sudo chmod +x /home/user/4.3.ephemeral.sh
sudo ./4.3.ephemeral.sh

Option 1: Install and Make Qubes Use 100% dom0 in RAM

To use appvms and templates 100% in RAM, you need to create appvms, disposable templates, and disposable VMs or templates in varlibpool that resides in dom0! The Qubes environment becomes hybrid; everything in dom0 stays 100% in RAM, but VMs in the VM pool on SSD or HDD will function normally, although they are not in RAM!

Upon reboot, the option y/n will appear; use y to run Qubes in live mode like Tails! Use n to continue using dom0 on the regular SSD!

Attention: When using dom0 in RAM, you should not create appvms or templates in the VM pool because after restarting the system, it will not recognize the appvms or templates created since dom0 was in RAM, and records will be lost upon shutdown. However, the partitions will remain on the SSD but inaccessible to dom0!

Use the option n on reboot to enter Qubes with normal dom0! If you configured Qubes to use dom0 with 15 gigabytes of RAM, entering normal mode with option n, those 15 gigabytes will remain allocated to dom0, which is a waste of RAM since dom0 only needs 4 gigabytes as per the default installation! That’s why the script has Option 2, which restores everything to original conditions and allows dom0 to use 4 gigabytes, giving the rest of the RAM for other VMs to use freely!

Option 2: Restoring Default Qubes Settings

From reboot:
Choose option n
sudo ./4.3.ephemeral.sh

Choose option 2
Reboot

Your Qubes has returned to normal, and the y/n option to enter Qubes in live mode will no longer appear at boot!

Attention:

By default, dom0 comes with 20 gigabytes, and it initially occupies 6 gigabytes of the system! Templates are generally large, and to add a lot of templates totaling, for example, 40 gigabytes, you would need to:

  • Increase the size of the dom0 partition
  • Have more RAM to accommodate this!

Script Source and Improvements

The source of the script came from the official Qubes forum through various posts, and thanks to them, I developed this:

Improvements This Script Provides:

  • Configuration of grub files, fstab, and scripts for dracut modules are created, along with original backups being made.
  • The script prevents a novice user from setting the RAM value above the total RAM available.
  • The script prevents a novice user from setting a RAM value lower than what dom0 currently has in files. For example, if dom0 has 10 gigabytes of files and the user requests 8 gigabytes to run Qubes in live mode, the script will block this!
  • Rounding for zram: If the user chooses 10,200 megabytes to allocate to dom0 in RAM, it rounds to 10G in zram; if they choose 10,900 megabytes, it rounds to 10G in zram. This logic follows, and the user must be aware of it!
  • The script prevents the user from restoring Qubes to its original condition if dom0 is 100% in RAM, as recompiling the initramfs, image, and grub would prevent booting later.
  • It includes an automated option (Option 2) to restore to the original version, since using Qubes with the “n” option will not revert dom0 to the standard 4 gigabytes of RAM. Instead, it will continue to use the same amount of RAM for the previously chosen live mode, which is inefficient because it wastes RAM. Restoring everything with this option avoids this issue.
  • Each new version of Qubes may require creating a new version of the script to adapt to changes, as I did when transitioning from Qubes 4.2 to 4.3!

Test it and provide feedback and suggestions for improvements to the script!

Challenges for Forensic Experts

Using Qubes in live mode 100% in RAM, running VMs in varlibpools within dom0 100% in memory RAM: will it achieve the same amnesic effect as Tails Linux within Qubes? For forensic experts, use it and attempt to recover traces, data, metadata, etc., and report here if you succeed so that this tool can be improved!

Using a template called template1 in the VM pool and appvm1 in varlibpool with dom0 100% in RAM using this script: will there be traces or metadata of appvm1’s activities in the partitions where template1 resides in the VM pool on SSD or HDD? For forensic experts, if you find anything in your tests, please inform us here. I mention this because using templates in the VM pool and appvms in varlibqubes with dom0 100% in RAM is necessary; using everything on dom0 would require many gigabytes and significantly more RAM, which not everyone will have available to meet that demand!

1 Like

You can add two scenarios to your script, as described: Qubes OS live mode. dom0 in RAM (zram0, overlay in tmpfs). Protection against forensics. Tails mode

The second scenario (overlay in tmpfs), used by native kicksecure/Whonix, is more secure:
Root filesystem is effectively read‑only
The system runs on an overlay: the original root is mounted as lowerdir=/live/image (read‑only view), and all changes go into upperdir=/cow/rw on tmpfs. This makes it hard for malware to persist on the real disk, since any modifications live only in the volatile upper layer.
Overlay in tmpfs does not create and format new block devices nor copy the entire root filesystem at runtime. There are fewer points where an attacker could hook into disk‑level operations or tamper with filesystem creation and bulk copying.
A separate mkfs and bulk copying with cp ‑a is a much more vulnerable scenario than creating an overlay.
The only advantage of working with zram0 is memory savings.

Both scenarios need to use appVM in varlibqubes or new pool inside dom0. It’s sufficient to run only the appVM, templates don’t retain session metadata. It’s also preferable that new qubes be created in the varlibqubes pool and destroyed after shutdown. Otherwise this qubes will remain on disk but become inaccessible to dom0 after a reboot.

1 Like

The script does everything automatically!
No need to configure anything…
If I want to change from 10 gigabytes to 15 gigabytes, at the beginning it already asks and makes all the modifications and compiles everything…
It also allows me to go back to the normal qube, as I choose 12 GB of RAM; the dom0 will always have 12 GB of RAM even if I want to use the persistent qubes with the ‘n’ option at boot… and for those who only have 16 GB of RAM, this is a hassle… being stuck with 12 GB locked to dom0 unnecessarily…
The script has this option 2 that returns to normal, and dom0 goes back to having 4 GB of RAM!
Now, when I want to use qubes 100% in RAM, I just use option 1; when I want to return to using normal qubes and not waste RAM in dom0, I use option 2, and everything returns to normal!
The amazing thing is that everything is done automatically and has all the handling that a novice needs!
Everything from the post Qubes in tmpfs 🤫 is being done by the script quickly… that’s what we needed…
Now we can quickly use qubes in RAM like Tails… and it’s much more secure than Tails!
The Qubes developers should add this option automatically through a button in the graphical interface for Qubes to do this, and instead of having a shell script, everything would be in a graphical interface, making it even easier for a novice!
The Qubes team should be interested in this so that Qubes does what it does and, in addition, does it like Tails completely amnesic and anti-forensic for certain needs that some have!
Running Tails inside Qubes is not worth it, as it does not allow connecting USB drives or transferring or receiving files due to incompatibility with other Qubes VMs!
Request that the Qubes team implement this in the next Qubes 4.4, but everything in a graphical interface!
It doesn’t seem difficult if a shell script can do this!