Delivery-Date: Fri, 17 Apr 2015 01:55:30 -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.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD 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 6C8811E0B94
	for <archiver@seul.org>; Fri, 17 Apr 2015 01:55:27 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 9CEC5338F6;
	Fri, 17 Apr 2015 05:55:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id C47F5338CF
 for <tor-talk@lists.torproject.org>; Fri, 17 Apr 2015 05:55:21 +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 qKWHESt2n3-8 for <tor-talk@lists.torproject.org>;
 Fri, 17 Apr 2015 05:55:21 +0000 (UTC)
Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42])
 by eugeni.torproject.org (Postfix) with ESMTP id 9B69F33842
 for <tor-talk@lists.torproject.org>; Fri, 17 Apr 2015 05:55:21 +0000 (UTC)
Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net
 [50.184.63.128]) (authenticated bits=0)
 by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t3H5tHpK026893
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
 Thu, 16 Apr 2015 22:55:18 -0700 (PDT) (envelope-from yuri@rawbw.com)
X-Authentication-Warning: shell1.rawbw.com: Host
 c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be
 yuri.doctorlan.com
Message-ID: <5530A043.6040107@rawbw.com>
Date: Thu, 16 Apr 2015 22:55:15 -0700
From: Yuri <yuri@rawbw.com>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Tor Talk List <tor-talk@lists.torproject.org>
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>
In-Reply-To: <485a588c9c39732ee1af0af254e9223c@riseup.net>
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 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
-- 
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

