Forensic-Timestamp Metadata Risk in Qubes DVMS (ZRAM) and Why It Matters
Question
In /home/user/.local/share/applications there are many .desktop launcher files for dom0-visible apps.
When a user starts (for example) a DVM such as anon-whonix-zram created from a zram_pool (amnesic), a related .desktop file may exist such as:
/home/user/.local/share/applications/org.qubes-os.qubes-vm-settings._anon_dwhonix_dzram.desktop
Those launchers contain an Exec= line (and related entries like X-Qubes-*).
For example, a desktop entry like:
org.qubes-os.vm._anon_dwhonix2_dzram.pcmanfm-qt.desktop
may include:
Icon=/home/user/.local/share/qubes-appmenus/anon-whonix2-zram/apps.icons/pcmanfm-qt.pngExec=qvm-run -q -a --service -- anon-whonix2-zram qubes.StartApp+pcmanfm-qt
I don’t fully understand all the Qubes mechanics here, but my understanding is: when you click an app/menu icon, Qubes reads the .desktop file and executes the command in Exec (or uses X-Qubes-DispvmExec depending on disposable mode).
Then the key point: it may not run automatically when the VM boots, but it does get accessed when the user launches the app.
That access can update file metadata timestamps. An attacker conducting forensic analysis could examine and correlate time relationships, including:
- when
.desktoplaunchers were accessed - the same for this .png and others like that → /home/user/.local/share/qubes-appmenus/anon-whonix2-zram/apps.icons/pcmanfm-qt.png
- when the DVM/app was started or stopped (repeated over many sessions)
- correlation with other online activity happening at matching times
If an app like anon-whonix-zram was started and terminated many times, and on the same days and at the same times some online activity occurred within the same time windows—using Tor, and remembering that anon-whonix-zram uses Tor—then it can become useful timing evidence, potentially enabling de-anonymization.
Because of this, I believe timestamps associated with .desktop launchers (and similar files), .png etc… should be prevented from being written in durable storage.
What “file timestamps” mean
File timestamps are date/time values stored by the filesystem that represent different kinds of events that occurred for that file. Mainly:
- mtime (modification time): last time the file content (or relevant file data) changed.
- atime (access time): last time the file was read/accessed.
- ctime (status change time): last time file metadata/status changed.
- birth time (creation time): when the file was created (not always available/maintained depending on the filesystem).
Why clicking the menu can leave forensic traces
If, every time a user clicks an icon to launch an app inside a ZRAM-backed DVM/VM, the system accesses one or more .desktop files, then their timestamps (atime/mtime/ctime) can be updated.
Even if Qubes uses tmpfs-based amnesic logs for command history (or keeps many operational logs ephemeral), the .desktop file metadata may still persist on disk.
An attacker could then collect those timestamps and infer usage patterns.
That is why the mitigation strategy should not be limited only to logs. Any filesystem objects related to VM launching that produce timestamps (including .desktop, icons, and related Qubes menu/appmenu files) should be handled in a way that keeps them ephemeral (e.g., tmpfs/zram/overlayfs), or otherwise prevents timestamp persistence.
If those objects are not made ephemeral, the setup is not guaranteed to be “100% anti-forensics,” and remaining timestamp artifacts can still be dangerous. From an usability standpoint, a fully ZRAM/overlayfs-based approach may be preferable to brittle low-usability methods.
Tails as a reference model (amnestic + usable hybrid)
Tails enables amnesia while still allowing useful persistence via a hybrid approach.
Example: the user may store a Bitcoin wallet in an encrypted persistent folder. Data and logs related to operations in that persistent folder remain there, but other activity outside that encrypted folder remains ephemeral/amnesic.
Qubes would need an approach similar to hybrid amnesia + persistence to match Tails usability.
One referenced path is the “live mode / dom0 in RAM / non-persistent boot / RAM wipe protection … Tails mode hardening … ephemeral encryption” approach from the Qubes forum thread:
However, approaches like that may be difficult to use in practice (usability issues).
Ideal goal (concept)
The ideal approach would be:
- Keep the DVMS in a
zram_pool(amnestic behavior). - Also ensure that directories/files that produce persistent timestamps are placed in ephemeral storage (RAM) or otherwise made non-forensic.
- Avoid any workflow where launcher-related metadata persists on disk and can be correlated.
In that design, Qubes would resemble a Tails-style hybrid!
/home/user/.local/share/ is one example, but other directories and other files can leave traces. Something in the DVM within a zram_pool created by user commands is also necessary to investigate, and all of it needs to be examined!