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?

Hopeful Fork

You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to