Effectiveness of the VM compartimentation

[nosugar...@gmail.com]

Hi all,

Right now I use Qubes for a bit of fun - setting up VPN's - chaining them, trying to get HVM's up and running, just messing about. I do plan to totally phase out my other OS's for it, but theres one thing that keeps going through my mind.. how isolated are the VM's from each other actually?

I know Qubes is 'reasonably' secure, but how secure? Could a whistle blower have a whonix VM open handling sensitive materials while at the same time have a personal VM with ISP connection and google/facebook/work sites open, with no issue at all? If the whistleblower would only be able to use the machine for sensitive purposes due to leak potentials, etc, wouldn't this make using Qubes pointless?

Thanks.

[Chris Laprise]

Of the myriad remote attacks that can be used against traditional
operating systems, basically one type is thought to be effective against
Qubes in general: Side-channel attacks.

https://en.wikipedia.org/wiki/Side-channel_attack

The best way to mitigate these is to not run public key crypto in
trusted VMs at the same time untrusted VMs are running (although this
can be a problem when VMs like sys-net and sys-usb are considered).
Also, test your hardware to see if its susceptible to rowhammer.

In contrast, even a physically isolated system can be less secure than a
Qubes system. This is because the devices and drivers used for
interfacing (SD cards, DVDs, USB drives - even occasionally) are much
more complex and vulnerable than the interfaces on a Qubes VM. And if a
Qubes VM does become compromised, chances are much better that the core
system and firmware will remain safe.

https://blog.invisiblethings.org/2014/08/26/physical-separation-vs-software.html

Finally, assuming that attacks will succeed at least occasionally (and
Qubes is built with this assumption for guest VMs): How recoverable is
the situation? A Windows system that had its firmware compromised will
continue to run malware even after the OS is wiped and re-installed. A
Qubes system OTOH probably has intact firmware and malware can be
removed by removing the affected VM.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[nosugar...@gmail.com]

Thanks for the reply, Chris.

So, apart from the rare chance of a side-channel attack. One should be able to surf safely in Whonix, or a private VPN'd VM, while being able to surf regular sites such as this google hosted mail group on another without overlap, or the data from Whonix hitting a non-torified machine?

[Chris Laprise]

Yes, I believe the isolation in that context to be excellent, especially
since Qubes 4.0 now uses hardware isolation for VMs (PVH mode instead of
PV). PV mode had allowed some containment issues to arise in the past,
but hardware virtualization capability has become widespread enough (and
better supported in Xen) such that the new PVH mode could be used for
better isolation.

-

As for side-channel attacks, they are thought to be rare and difficult
to execute but I wouldn't count on it remaining that way. Tor Project
appears to be testing constant-time crypto to avoid some of the worst
side-channels:

https://trac.torproject.org/projects/tor/ticket/18896

Other improvements in side-channel resistance will come not from crypto
code but from better hardware such as RAM and CPUs. I believe you can
get somewhat better resistance already by using AMD instead of Intel
CPUs, as AMD appear to take fewer shortcuts and fare better against
Spectre and Meltdown, for example. ECC RAM support is also more
prevalent in AMD products, and this provides some protection against
rowhammer.

In the long term, some of us are hopeful that open source hardware could
address these nagging issues, as well as the issue of possible backdoors
in hardware and firmware. We have some advocates here for OpenPOWER,
although Qubes cannot yet run on it.