Currently any AppVM has persistent storage, it is referenced by default at
least as /home, /rw/config, /usr/local. And software is executed from this
persistent storage from read-only system.
This allows an adversary to install persistent AppVM exploit e.g. via ~/.bashrc
or /rw/config/rc.local. Advanced exploit can then hide its own invocation
script, so it won't be possible to detect it from running VM itself (at least
aafter /rw/config/rc.local is executed; so better check when VM is turned off).
I suppose that it is by design and that won't harm other, trusted VMs (with an
exception of unclear consequences of mounting this rw partition in another
dom). But there is a threat model when persistent exploit of untrusted vm
matters - the one when user wants to maintain anonymity.
For example, a persistent exploit in network vm can be used to defeat MAC
randomization and track user location; it can even help mount attack against
Tor for an adversary that isn't user's ISP - exploit can monitor outgoing Tor
traffic and check correlations with incoming traffic of investigated sites
(that are within adversary's ISP).
If the same is applicable to Whonix VMs, then it is even worse to anonymity:
persistent exploit in Gateway completely defeats Tor while persistent exploit
in Workstation can be used to deanonymise user via correlation analysis if
attacker is controlling user's ISP (in this case attacker can send a controlled
data stream to its own server over Tor and monitor incoming Tor traffic at ISP
Basically, as a user with threat model that involves maintaining anonymity, I
cannot rely on stock Qubes now - at least untrusted VMs should be created from
templates each time I need them - and that is inconvenient and may have other
I haven't found any public discussion of this persistent storage exploits -
could you please point me to it if it is already covered? Any ideas how to
address this issue properly?
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.