Delivery-Date: Mon, 15 Dec 2014 09:20:47 -0500
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.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD,URIBL_BLOCKED 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 ACAE41E045E;
	Mon, 15 Dec 2014 09:20:45 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 5FD1531E6B;
	Mon, 15 Dec 2014 14:20:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id E91CF31DBB
 for <tor-talk@lists.torproject.org>; Mon, 15 Dec 2014 14:20:37 +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 3IUzVv7Lrxl6 for <tor-talk@lists.torproject.org>;
 Mon, 15 Dec 2014 14:20:37 +0000 (UTC)
Received: from quidecco.de (quidecco.de [81.169.136.15])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id B88B22848A
 for <tor-talk@lists.torproject.org>; Mon, 15 Dec 2014 14:20:37 +0000 (UTC)
X-Greylist: delayed 3357 seconds by postgrey-1.34 at eugeni;
 Mon, 15 Dec 2014 14:20:37 UTC
Received: from localhost (localhost [127.0.0.1])
 by quidecco.de (Postfix) with SMTP id AD17DE23534;
 Mon, 15 Dec 2014 14:24:35 +0100 (CET)
From: Isidor Zeuner <onions@quidecco.de>
To: tor-talk@lists.torproject.org
Message-Id: <20141215132435.AD17DE23534@quidecco.de>
Date: Mon, 15 Dec 2014 14:24:35 +0100 (CET)
Subject: [tor-talk] responsibility for enforcing secure Tor usage
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>
MIME-Version: 1.0
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>

Hi there,

I was thinking about possible improvements for how setups using Tor
enforce secure (privacy-concious) usage of Tor.

Consider for example torsocks. If I use torsocks in order to connect
to a Tor daemon, torsocks will prevent the application from doing DNS
queries. But if it didn't, the Tor circuits it initiated could be
considered as "tainted" because an attacker could correlate the DNS
traffic with the traffic coming from the exit node.

This is probably well-known, but what struck me is that it's
torsocks which does the important work here. Any client software which
has access to the Tor daemon would have the option to taint the Tor
daemon.

So, why not improve the security by using modern operating system
security mechanisms? Using granular capability-based access controls,
the operating system can prevent processes from accessing both Tor and
non-Tor sockets. Furthermore, communication between Tor-based and
non-Tor-based network clients can be restricted. Ideally, it should be
possible to create a system where only Tor and the access control
policy must be audited in order to be sure that attacks based on
correlating Tor and non-Tor connections cannot be applied.

I know that for many setups, this would mean additional effort on the
operating system layer, but the general interest in security is
becoming larger, so I could imagine that efforts like this can attract
some user and developer dedication.

Any comments are appreciated.

Best regards,

Isidor
-- 
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

