[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tor-talk] [tor-dev] Porting Tor Browser to the BSDs

On 2015-04-17 5:55 am, Yuri wrote:
On 04/14/2015 15:38, WhonixQubes wrote:
-- Harder:  Whonix with VirtualBox, KVM, etc isolation for Tor

--- Hardest:  Whonix with Qubes isolation for Tor

I only don't understand why you are you so sure that the system with
the hypervisor involved is more secure. Just because something relies
on the "bare metal" doesn't mean that it is inherently more secure. I
will give you two examples of compromised hardware:

* Certain three letter agency managed to subvert some BIOS
manufacturers to https://pbs.twimg.com/media/Bd7LUMYCMAAJcqJ.jpg to
inject malicious code into the kernel during the last stage of BIOS
boot. In such case system boots up in already compromised state, and
this is virtually impossible to detect. This can quite easily include

* Intel manufactures many (or all) their network cards with something
called Active Management Technology included:
https://en.wikipedia.org/wiki/Intel_Active_Management_Technology Such
cards are able to connect to some remote locations even without the
running OS. And I am sure that even with the OS running they probably
can also initiate connections and send some data out. Nobody but Intel
knows what such cards really do.

Virtual machines already provide very high security, practically
infeasible to exploit. Qubes provides an improvement on top of
"practically infeasible". So this is the hair splitting situation,
with very marginal risk difference, and other factors like the
possibility of the compromised hardware might easily be the higher
risk compared to this difference.


Hi Yuri,

Yes, I am aware of these exploits and agree that Qubes is indeed vulnerable to the most advanced low-level hardware, firmware, side channel, evil manufacturer, and evil developer attacks.

I'm also not arguing security of hypervisor vs. bare metal inherently as generic technologies.

I'm saying, standing on their own, the security architecture of Qubes is meaningfully stronger than bare metal Linux.

And I'm not basing the argument only on the listed top 1% of most advanced attacks that can cut through any system -- even Qubes.

It changes the argument entirely to ONLY focus on that top 1% of the most strongest exploits. If only focusing on these, then sure, I agree.

That's like saying just because an atomic weapon can equally destroy both a bank vault and a cash register with ease, that there is no security difference between the two.

Most real world systems are usually not up against such attacks. Another way to say this is that, out of all the total computer exploits actively happening in the world every day, month, year, the vast majority are not the ones that can get past the security of Qubes.

A good number more attacks could actually get past the security of bare metal Linux though, which shows the difference and makes my point about relative security strength.

In bare metal Linux, for example, just viewing a malformed webpage, pdf, email, etc could pwn your total system (!!!).

So I'd rather run with some VM containment than none.

And most hypervisors, especially Type 2 (installed like VirtualBox), are subject to much greater attack surface than Qubes, and generally poorer security engineering.

Overall, I'm saying for the majority of real world exploits, there is a meaningful security difference between the actual TCB attack surface:

Bare Metal Linux > Typical VM Linux (VirtualBox etc) > Qubes VM Linux

Yes, there is still open TCB attack surface on ALL systems, including Qubes, but there is meaningfully less, when comparing against all different classes of real world attacks, due to Qubes' purposefully isolated non-monolithic architecture and lower LOC count.

More info:

- https://www.qubes-os.org/doc/QubesArchitecture/

- http://www.invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf

- http://files.qubes-os.org/files/doc/arch-spec-0.3.pdf

And my next major project will hopefully overcome most all of the top-tier low-level exploits you mentioned and shift us further towards truly bulletproof security + anonymity systems. :)

tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to