I was hopeful it would allow that, but unfortunately it doesn’t yet. Live mode requires using an in-VM kernel with Dracut, and boot modes are only supported when using a dom0-provided kernel right now. There is ongoing work to get in-VM kernel support for boot modes, but it requires a GRUB patch which I’m still working on getting upstreamed and integrated into Qubes OS.
@arraybolt3 Hello. You can enable ephemeral encryption for the root and volatile partitions in appVMs through these commands: vm-pool set vm-pool -o ephemeral_volatile=True qvm-volume config appvm:root rw False In this guide, private volume directories are also encrypted. Maybe implement full ephemeral encryption instead of live mode? It could make Qubes more secure and private for all appVMs. You already created a tool for keyboard fingerprint protection for Qubes. You can implement ephemeral encryption for the private volume and the Qubes team would welcome your development. You have authority in the Qubes community and your developments make Kicksecure and Qubes incredibly private and secure. It seems to me that implementing this would be simpler than live mode. And ephemeral encryption is better than working in RAM.
It sounds like an interesting idea. I would push back a bit against the idea that ephemeral encryption is better than working in RAM from a security standpoint though; data that doesn’t exist anymore is more secure than data that exists but is hard (to the point of theoretically impossible) to read. Data in RAM vanishes once the power turns off (usually almost instantly, sometimes it takes a while), so it’s easier to trust that the data is really gone is it only ever touches RAM. That being said, this would probably be better than unencrypted DispVMs on Qubes.
It sounds to me like this “full ephemeral encryption” would only really be an option for disposable VMs, which is the closest thing Qubes has to “live mode” at the moment. The main reason live mode would be useful under Qubes is not security though, but usability; live mode on non-Qubes-Whonix allows one to access any data they already saved to their machine, while preventing any new data from touching the disk. Under Qubes, the closest thing one can do is copy needed files into a DispVM for use, and accept that they will be lost when the VM is powered off. That’s not as good of a UX.
Maybe ephemeral encryption + some way to automatically provision a DispVM’s contents from an existing AppVM would work…
Please be aware that @arraybolt3 works with Kicksecure, Whonix under contract and not as a volunteer. Maintaining Whonix causes expenses (money, work hours). For these reasons, please don’t tag @arraybolt3, so that I can triage/prioritize issues before assigning them to @arraybolt3.
Okay then it will help save money for the contract, since creating a kernel patch for Qubes from scratch requires more time and mental effort than improving an existing built‑in Qubes default feature.
@arraybolt3 I think the ideal approach is to keep the live mode for Kicksecure‑Host and add ephemeral encryption to Kicksecure‑AppVM - Qubes consumes a lot of RAM and the system can freeze if the device has only 16 GB of RAM.
I’m using that guide for Kicksecure‑AppVM, and it works perfectly. But I believe you can make this feature even better and simpler - possibly by analogy with Qubes’ default behavior for the root volume: private volume - read‑only lower overlay and a read‑write upper overlay in an ephemerally encrypted volatile volume. Some regular users have already found “workarounds” for this scenario, and I think you’ll be able to develop it quickly.
You’ve added so many great features to Kicksecure‑Whonix that I think this will be an easy and quick task for you, allowing Patrick to save the budget for other developments.
[user ~]% lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS xvda 202:0 1 20G 1 disk ├─xvda1 202:1 1 200M 1 part ├─xvda2 202:2 1 2M 1 part └─xvda3 202:3 1 19.8G 1 part └─dmroot 253:0 0 19.8G 0 dm /rw /var/lib/whonix /var/cache/anon-base-files /var/lib/dummy-dependency /var/lib/sdwdate /var/cache/setup-dist /var/lib/canary /var/lib/systemcheck /usr/local /var/spool/cron /home / xvdb 202:16 1 2G 0 disk xvdc 202:32 1 12G 0 disk ├─xvdc1 202:33 1 1G 0 part [SWAP] └─xvdc2 202:34 1 11G 0 part └─dmroot 253:0 0 19.8G 0 dm /rw /var/lib/whonix /var/cache/anon-base-files /var/lib/dummy-dependency /var/lib/sdwdate /var/cache/setup-dist /var/lib/canary /var/lib/systemcheck /usr/local /var/spool/cron /home /
new data is not being saved. I have data only up until the launch of the amnesiac mode. this seems similar to the live kicksecure mode. It appears to work well. however, now dvm-template also has amnesia. previously, I ran dvms in ram using another qubes guide - it worked reasonably well, but if I opened many browser tabs, dvm would suddenly shutdown, or I saw experiencing glitches in dom0. I have 16 gb ddr4 ram.
For clarification, the bootloader patch is happening one way or another (really it already happened, upstream GRUB accepted it) since it’s a step towards getting Whonix to use in-VM kernels under Qubes, which will be a security improvement for a number of reasons.
@arraybolt3 Amazing! Great work! It’s a shame it will only be added in the next version of Qubes.
If I understand correctly, it will allow running custom AppVM boots - full ephemeral encryption for devices with 16 GB of RAM, or a live mode for devices with 32 GB of RAM.
