[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Tor + SELinux sandbox = leak proof without VM overhead?
- To: or-talk@xxxxxxxxxxxxx
 
- Subject: Re: Tor + SELinux sandbox = leak proof without VM overhead?
 
- From: coderman <coderman@xxxxxxxxx>
 
- Date: Mon, 23 Aug 2010 10:56:53 -0700
 
- Delivered-to: archiver@xxxxxxxx
 
- Delivered-to: or-talk-outgoing@xxxxxxxx
 
- Delivered-to: or-talk@xxxxxxxx
 
- Delivery-date: Mon, 23 Aug 2010 13:57:00 -0400
 
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=gmail.com; s=gamma;        h=domainkey-signature:mime-version:received:received:in-reply-to         :references:date:message-id:subject:from:to:content-type         :content-transfer-encoding;        bh=b6c/1Y/RZ63IADRJiFtE5xOn4gMtSeJ25w4UHfV9cRc=;        b=IRhaddriLSSohCYIlM+uGJ4hvvhJDOkzm5J15B0fJCUjmwVlpvGlNaWlQh7FVjoOXC         w8xuZGURe0Hk4CLUBA0qKJLbcGMr7yYCNYd3YC3w1q/71UQqf4G0cazwDPWhWx6WOnSM         afZ+ZW7zoIgdZXm/2ThOa7JXPqCpB2fl+aWk8=
 
- Domainkey-signature: a=rsa-sha1; c=nofws;        d=gmail.com; s=gamma;        h=mime-version:in-reply-to:references:date:message-id:subject:from:to         :content-type:content-transfer-encoding;        b=ed1TdzVxz0iVIJDjvJjIxOzJTzay7T3Tn5ePr0x+tsnfR3oSX8BQF6MfJzAurnzr2l         cBHuHab8bpkwEIM4ELMf2XQuYRr1FINgz54z7g1CY0IMm2zIdTnK1ifsrUQ7a4B2cUxL         1z7Q9VJDELvetU4iRKz1/eB4bnqPbcaKN8SeQ=
 
- In-reply-to: <AANLkTika511+Ps71qdpZBOSxcv77bW3c1giVQkHu5Dx-@xxxxxxxxxxxxxx>
 
- References: <AANLkTika511+Ps71qdpZBOSxcv77bW3c1giVQkHu5Dx-@xxxxxxxxxxxxxx>
 
- Reply-to: or-talk@xxxxxxxxxxxxx
 
- Sender: owner-or-talk@xxxxxxxxxxxxx
 
On Sat, Aug 21, 2010 at 5:55 PM, Gregory Maxwell <gmaxwell@xxxxxxxxx> wrote:
> ...
> I think it's obvious that the best way of using tor is running your
> torrified apps in a VM which can only access the outside world via
> TOR. This provides the highest protection from network leaks and also
> partially thwarts fingerprinting.   But I can only assume that the
> 'cost' (performance, complexity, etc) of using a VM for tor is too
> high for many people— otherwise we would insist that anyone who wants
> anonymity operate that way.
not a silver bullet, but tends to fail safer.
the "costs" include:
- elevated privs for accelerated virtualization / para-virtualization.
Tor by default does not require such.
- additional resource consumption. isolated os, network stacks, and
applications require additional memory and CPU.
- only solve part of the problem; you still need Torbutton and other
application level protections, even if direct proxy-bypass type
disclosures of endpoint or identity are mitigated.
ideally this model would apply across the entire user experience, see qubes:
 http://qubes-os.org/Home.html
> Has anyone looked into using the SELINUX sandbox
> (http://danwalsh.livejournal.com/28545.html) to prevent leaks?   The
> sandbox provides a high degree of application isolation.  It looks
> like it would be pretty much trivial to add an option to the sandbox
> front end program to only allow accesses to the tor socks port from
> the isolated app.
developing and maintaining a robust RSBAC policy is non-trivial. that
said, these are complementary techniques. a strong RSBAC model around
and within virtual machine based isolation provides additional defense
against application errors, vm break-outs, etc.
it doesn't help that a lot of the good SELinux policy development /
management tools are closed source / proprietary.  it's not the only
game in town...
> With this users on a supporting platforms wouldn't have to use
> wireshark to figure out if, say, pidgin, is leaking via DNS. They
> could simply run the app inside the sandbox and be sure of it.
there's RSBAC bypass just like vm break-out; anyone claiming
infallibility is smoking something or selling you lies...
> Does this sound like a practice which should be refined and recommended?
absolutely! you could submit a series of policies for various Tor
modes of operation and solicit feedback / commit to contrib.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/