Qubes in tmpfs 🤫

[qstateless]

Hi @nealr

Good thoughts…

@nealr

If something in a VM can reach out and compromise dom0, it’s already compromised Xen, and it can fiddle with VMs on disk. I guess dom0 mods for persistence, something that kinks one or more VMs each time the system started, would be a potential problem?

From a hardcore security perspective, you are generally right that a traditional boot drive is still accessible and writable, even with Dom0 running from RAM. So a breakdown of Qubes OS security via a Xen VM breakout exploit could still compromise one’s system across restarts, if a persistent drive is used.

@nealr

Isn’t there a trusted boot process that would render persistence impossible?

Detectable at least, with a TPM. I’ve read about things like UEFI Secure Boot, Heads, Anti Evil Maid, TrenchBoot (currently being integrated for Qubes AEM by 3mdeb), etc.

@nealr

I can see where this would be useful for a live USB setup, but I think it would be better as a live DVD, a sort of "take your hard drive free laptop to DEFCON’ kinda thing, where you can leave it sitting somewhere and nobody can do anything that would survive a restart.

Yes. Using write-protected USB or read-only DVD boot media would certainly increase one’s ability to eliminate the possibility of persistent exploits that could otherwise survive a system restart.

@nealr

I am not sure what value there is to having dom0 running from ram on a system that does have a disk.

I see a few general reasons for making a Qubes Dom0 boot session be disposable in RAM…

• System Administration
• Anti-Borking
• Anti-Forensics
• Anti-Fingerprinting
• System Security

System Administration:

• Having to account for and manage less state in less places can generally help ease sysadmin burdens. I personally take advantage of this benefit across a small fleet of multiple computers I administer. I’m planning to go further and use this to eliminate the use of local drives via RAM-based Qubes OS over PXE Network Boot.

Anti-Borking:

• If one wants to run scripts, tests, etc that might bork or mess up one’s Dom0, then running from RAM allows for a quick reset to clean system state. I personally have a Qubes-based development test computer setup specifically for this.

Anti-Forensics:

• On a normally-functioning and non-compromised system, one can achieve a greater level of anti-forensic / disposable computing for the entire Qubes OS system by having no Dom0 logs/state saved.

Anti-Fingerprinting:

• If someone needed their Qubes OS environment to have the same fingerprint between multiple restarts, then a RAM-based Dom0 would help with achieving that.

System Security:

• With a persistent boot drive, while running Dom0 from RAM, a Dom0 exploit would have to take the extra step of reaching out to compromise the drive or drive contents, beyond compromising the running Dom0 environment within RAM. So there would probably be some unaware exploits that do not assume Dom0 is even in RAM, where one’s system could be further protected against such exploits from persistent compromise beyond a restart. Not absolute security, but one more step further.

Of course, one could potentially use write-protected USB or read-only DVD boot media too. I experimented with RAM-based Dom0 and write-protected USB last year using Qubes 4.1, which I believe I wrote about some in this thread.

Layering various system attributes can potentially increase the fitness of a RAM-based Dom0 for various use cases and use conditions. A RAM-based Dom0 is another key attribute of choice that is now accessible to all who may find a use for it. Big thanks to @xuy for the technique.

Thoughts?