Fully Ephemeral DispVM's

fsflover · June 17, 2022, 10:10pm

Just to have links here to related issues, for completeness:

DisposableVMs: support for in-RAM execution only (for anti-forensics)

opened 05:21PM - 08 Mar 15 UTC

T: enhancement help wanted C: core P: major crypto pr submitted C: storage

**Reported by joanna on 25 Sep 2014 20:26 UTC** Currently volatile.img is being …backed up on the fs. See: https://groups.google.com/forum/#!topic/qubes-devel/QwL5PjqPs-4/discussion Migrated-From: https://wiki.qubes-os.org/ticket/904

github.com/QubesOS/qubes-issues

Disposable VMs and Local Forensics on qubes R4.0 context

opened 08:33PM - 29 Jan 18 UTC

Carl53

help wanted C: doc T: task

#### Qubes OS version: R4.0 #### Affected TemplateVMs: Documentation #…## Steps to reproduce the behavior: Go to page: https://www.qubes-os.org/doc/dispvm/#disposable-vms-and-local-forensics or https://www.qubes-os.org/faq/ ### Expected behavior: Information about how next Qubes version relate with this 2013 issue: https://www.qubes-os.org/doc/dispvm/#disposable-vms-and-local-forensics https://groups.google.com/forum/#!topic/qubes-devel/QwL5PjqPs-4/discussion ### Actual behavior: There is no information

github.com/QubesOS/qubes-issues

Reduce leakage of disposable VM content and history into dom0 filesystem

opened 05:32PM - 12 Apr 19 UTC

brendanhoar

T: enhancement help wanted C: other privacy P: default

**The problem you're addressing (if any)** Considerable information about the h…istory of disposable VM usage, as well as some contents of data from inside disposable VM leaks into the filesystem of dom0 and in most cases, survives reboots. In particular, the leakage into the xfwm4-*.state files (and lack of cleanup) is particular disturbing. e.g. in dom0 rm disp_files.txt # if exists rm disp_contents.txt # if exists sudo grep -rn '/' -e 'disp[0-9]' --exclude-dir={dev,proc,sys} | sort > disp_contents.txt sudo find / -name \*disp[0-9]\* | sort > disp_files.txt # matches references to disposable VM names in filenames Some findings on files related to disposable VMs (via disp_files.txt): 1. snapshots/volatile volumes for disposable VMs that were not shutdown correctly in the past (found in /dev/qubes_dom0/ and /dev/mapper/ ) 2. xml config files for the same in /etc/libvirt/libxl/ and /run/libvirt/libxl/ 3. appmenus for the same in /home/admin/.local/share/ 4. qrexec files for the same in /run/qubes/ 5. qubes.db pid and sock files for the same in /run/qubes/ 6. linux mapper links for the same in /run/udev/links/{\x2fmapper,\x2fqubes_dom0}/ 7. directories for the above in /var/lib/qubes/appvms/ 8. libxl logs for every(!!!) disposable VM ever run in this Qubes install in /var/log/libvirt/libxl/ 9. qubes logs for every(!!!) disposable VM ever run in this Qubes install in /var/log/qubes/ 10. xen console logs for every(!!!!) disposable VM ever run in this Qubes install in /var/log/xen/console/ Some finding related to files *containing* references to disposable VMs in dom0 (via disp_contents.txt): 1. Current and many historical disposable VM references are found in files in /run/udev/data/b253* files/nodes. 2. xfwm4*.state files in /home/admin/.cache/sessions/ contains *many references* to disposable VM *WINDOW TITLES* (application names, web site names, etc.) since the installation of the Qubes install (as well as current session). 3. .xsession-errors* in ~ reference many disposable VM names 4. /home/admin/.config/pulse/{guid}-stream-volumes.tdb a binary file appears to have 0..n matches on disp[0-9]. 5. /etc/lvm/backup/qubes_dom0 has current disp VM names plus some that weren't shutdown cleanly. 6. /etc/lvm/backup/qubes_dom0_* files have historical disp VM names. 7. /var/log/qubes/qubes.log* references historical disp VM names. 8. The systemd journal has a ton of historical disp VM references. 9. /var/lib/qubes/qubes.xml contains a lot of historical disp VM references. 10. /var/lib/backups/qubes/qubes*.xml contains a lot of historical disp VM references. 11. /var/lib/xen/userdata* contains a lot of historical disp VM references. 12. /var/lib/logrotate/logrotate.status contains a lot of historical disp VM references. **Describe the solution you'd like** 1. Triage of types of data leaking into dom0. 2. Based on types of data, develop a Qubes policy on eliminating, reducing, cleaning or ignoring the leaked data. 3. Based on type/policy, institute efforts to reduce the content stored into dom0 (at all vs. short term vs long term). **Where is the value to a user, and who might that user be?** All users who may want the historical content of the disposable VM usage not to be memorialized. Journalists, security researchers, etc. **Describe alternatives you've considered** None appear to cover 100% of use cases. Perhaps TAILS in an HVM might reduce it the most. **Additional context** **Relevant [documentation](https://www.qubes-os.org/doc/) you've consulted** **Related, [non-duplicate](https://www.qubes-os.org/doc/reporting-bugs/#new-issues-should-not-be-duplicates-of-existing-issues) issues** #3504 (similar, but does not provide a focus on specific leakage into dom0) #4408 (anti-forensics on swap files only) #1819 (anti-forensics request only covers the block devices for the VM) #1293 (similar to 1819) #3360 (specific to dom0 logging only) #2024 (emulating Tails' approach, dom0 leakage still possible)