The data copied to that VM (i.e. the pdf file or whatever you opened) must be considered leaked if the VM gets compromised via e.g. drive-by exploits. Agreed, it's limited to that data, but nevertheless an unexpected potential impact. And depending on your data it can be critical.
Well, that is why it is a distinct DispVM. If I open a legit PDF from my mail client in a DispVM (say dispvm1) and I open a non-legit URL in a DispVM, this will not be the same dispVM and thereby not leak the PDFs data. If the PDF itself is malicious, I most likely will not care about the leak. Only exception: A legit PDF gets infected and is then mailed to me. Usually that would allow the attacker to leak the PDF from the system it was send from in the first place.
From a usability point of view you'll also get annoyed if you cannot print in dispVMs just because your firewall rules allowing connectivity to your printer aren't inherited, but those to allowing connectivity to the internet suddenly are in place.
agreed, basically.

Btw inheriting netVMs makes a lot of sense if you imagine one Tor proxy VM and one directly connected one. So a dispVM from a Tor connected VM would spawn a direct internet connection in your case... Currently it fortunately does not.

Well, I was actually suprised that there is more than 1 DispVM. Do the child-DispVMs use the fedora-23-dvm template as well?

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply via email to