Delivery-Date: Fri, 17 Apr 2015 07:13:00 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY
	autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id DCACB1E0676
	for <archiver@seul.org>; Fri, 17 Apr 2015 07:12:58 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 55FDE3398F;
	Fri, 17 Apr 2015 11:12:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 068D7332B8
 for <tor-talk@lists.torproject.org>; Fri, 17 Apr 2015 11:12:51 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id BKvCdZPknksR for <tor-talk@lists.torproject.org>;
 Fri, 17 Apr 2015 11:12:50 +0000 (UTC)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id C1BEE20C4B
 for <tor-talk@lists.torproject.org>; Fri, 17 Apr 2015 11:12:50 +0000 (UTC)
Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
 by mx1.riseup.net (Postfix) with ESMTPS id 0053E40D7C;
 Fri, 17 Apr 2015 11:12:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1429269168; bh=c72J6VEqtKkYZmGeEnVahZwp5Lcn5QylKI5DRg6FVfc=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=M8Erur/XIC3rIn44JyqydDN953qMmMNQXh2VAy+BU7RFLc2y4a7ldI922QQnza0Ga
 sHKwi34MyZHPQNFEamSaNvkz8tv2rIgd2AbXDvFtw3eA9mhO6gXGwBbBzhjAUX97t4
 sIh/ZTpQELWAEJSlwAPtD/VJFGNWpxrXr96DaZJw=
Received: from [127.0.0.1] (localhost [127.0.0.1])
 (Authenticated sender: whonixqubes) with ESMTPSA id D1244400BB
MIME-Version: 1.0
Date: Fri, 17 Apr 2015 11:12:47 +0000
From: WhonixQubes <whonixqubes@riseup.net>
To: yuri@rawbw.com
In-Reply-To: <5530A043.6040107@rawbw.com>
References: <54E36CA2.9040504@mykolab.com> <5529BA28.30909@rawbw.com>
 <20150412064735.GA25987@inner.h.apk.li>
 <a6e97db5c897305c7dd655119c5eba57@riseup.net>
 <CAAgxajG9P07T0Ya_OyY4FS6ZO5HHBYQTYmttu34sp1oNseHL7A@mail.gmail.com>
 <3de2be9cc26c8e14281da15b6148681a@riseup.net> <552D8B97.3040407@rawbw.com>
 <552D9377.5030805@riseup.net> <485a588c9c39732ee1af0af254e9223c@riseup.net>
 <5530A043.6040107@rawbw.com>
Message-ID: <d52013d41f5a1869a088db7b88566223@riseup.net>
X-Sender: whonixqubes@riseup.net
User-Agent: Riseup mail
X-Virus-Scanned: clamav-milter 0.98.6 at mx1
X-Virus-Status: Clean
Cc: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] [tor-dev] Porting Tor Browser to the BSDs
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

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
> Qubes.
> 
> * 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.
> 
> Yuri


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. :)


WhonixQubes
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

