hopefulf...@tuta.io: > Hello, > > 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. >
There may be additional persistent storage enabled as well[1]. > 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). > Hence, all untrusted activity should be performed in a disposableVM or untrustedVMs with nothing of value. > 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). > I believe there is a ticket for disposable serviceVM (sys-net, sys-usb) functionality. Can't find at the moment. Unfortunately, there are some scenarios that Tor was never designed to defend against. A global passive adversary that can listen on both endpoints presents a vulnerability for any low-latency anonymity system[2]. Also, being a specific target opens up many additional non-technical avenues for deanonymization that may be trivially simpler than attacking Tor. In your example, it's not obvious that an adversary who can compromise and monitor your sys-net as well as the connections of all of the other compromised network connections can't simply compromise / coerce / subpoena ISPs to perform the same function at lower cost (legal / reputational / computational). > 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 level). > > 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 consequences. > > 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? > > > Thanks, Hopeful Fork > Your best bet to defend against persistent malware is to use Whonix-Workstation as your disposableVM template as previously suggested. Documentation is in-progress[3]. There is no additional threat to anonymity by using Tor all the time. Although stream isolation can effectively isolate your traffic across multiple Tor circuits, it is still advisable to use multiple VMs to separate your identities and never to use clearnet and Tor in the same VM[4]. You may find in certain cases, such as accessing your bank online, that you prefer to use a trusted banking VM connected directly to sys-net. Persistent storage in Whonix-Gateway is not only a matter of convenience - for storing files/settings - but can also be considered a security feature. Tor implemented persistent entry guards to reduce the likelihood of user traffic being intercepted by malicious entry guards[5] and this requires persistent storage. On the other hand, if you are a mobile user, you may worry about your entry guard footprint being used to track you[6]. In that case, you may prefer to follow the Tails model, recreate your Whonix-Gateway VM on a more frequent schedule, or use multiple Whonix-Gateways. The reason for isolating the Tor gateway from the user workstation in the first place is to be able to designate Whonix-Gateway as a trusted VM. Qubes VM isolation is relied on to maintain the integrity of Whonix-Gateway despite its connections to untrusted VMs. Whonix attempts to limit Gateway-Workstation interaction as much as possible to minimize attack surface - for example, via control port filters. Workstation compromise, persistent or not, is certainly a concern that is hopefully mitigated by layered hardening measures, such as Tor Browser and Apparmor. Again, in your example, you seem to assume the adversary is a global passive attacker with resources significant enough to monitor all the ISPs in a region / countr(ies). In such a situation, the attacker doesn't necessarily need persistent compromise to de-anonymize the user. Once they locate and compromise a Workstation of interest, they can simply send out signals in a pattern while monitoring the ISPs. You can mitigate this situation by using dispVMs, which contain no identifying information (documents, logins) and being judicious with the amount of browsing done per VM. Simply deanonymizing random Tor circuits to their server only reveals that the target is a Tor user. Ultimately, low-latency networks are not safe against this type of adversary regardless of countermeasures. Something like a high-latency mailer would be preferred. [1] https://www.qubes-os.org/doc/bind-dirs [2] https://svn.torproject.org/svn/projects/design-paper/tor-design.html #Section3.1 [3] https://forums.whonix.org/t/using-whonix-workstation-as-a-disposablevm-dispvm/2461 [4] https://www.whonix.org/wiki/DoNot [5] https://blog.torproject.org/category/tags/entry-guards [6] https://www.whonix.org/blog/persistent-tor-entry-guards -- 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 https://groups.google.com/d/msgid/qubes-devel/58b3b17c-ccfa-2861-7f03-ed90bc27744e%40gmail.com. For more options, visit https://groups.google.com/d/optout.
