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.
agreed.
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/a8dfee0a-0107-64f1-7ed2-8ae82809b638%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.