[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/