Re: Tor + SELinux sandbox = leak proof without VM overhead?
Hi, Geoff Down wrote (29 Aug 2010 20:00:55 GMT) : BTW is there somewhere from where the CACert root certificate (or fingerprint) can be downloaded with protection from an SSL cert I already trust? The above link, once corrected, generates an SSL warning. GD Debian (and derivatives) users can install the ca-certificates package = /etc/ssl/certs/cacert.org.pem Else, seems like the fingerprints are on the riseup helpdesk too: https://help.riseup.net/resources/europe/#boumorg Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr-fingerprint.asc | Did you exchange a walk on part in the war | for a lead role in the cage? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor + SELinux sandbox = leak proof without VM overhead?
Hi, Gregory Maxwell wrote (22 Aug 2010 00:55:49 GMT) : 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. I doubt there is something like the best way of using Tor. One always needs to balance the risks vs. the efforts needed to get some protection against it. More practically speaking: there are use cases the Tor Browser Button is perfect for, but it cannot prevent every leakage of anonymity to local disks. Then come Tor-ified VM setups that protect users a bit more but still somehow rely on the host operating system. Then comes running a Tor-ified Live system such as T(A)ILS [1] on bare metal. Each situation has its best fit solution but I don't think one solution can be told to be best in any cases. [1] https://amnesia.boum.rog/ 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. About performance: a five years old laptop with 1.7 GHz processor and 1GB RAM is able to run a fully-fledged Tor-ified desktop system such as T(A)ILS in VirtualBox. It was also true with qemu+kqemu last time I checked. About complexity: running a guest OS in a VM is really easy with VirtualBox (and presumably with its proprietary counterparts). But maybe I am missing the point. What kind of complexity are you talking of? Another cost mentioned by coderman was elevated privs for accelerated virtualization / para-virtualization. AFAIK VirtualBox does not need any special privileges (once the kernel part of the software is installed, and the modules/services loaded). Please don't misunderstand me. I'm not a fan of VM-based solutions and pretty much prefer the bare-metal + Live OS approach, but I feel we need to consider their pros and cons in a more detailed way than discarding them on the assumption that their cost must be too high else we would push for their usage much more than we do. 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. I'm sure there are use-cases such a sandbox would fit very well, and am in favour of developing new ways of using Tor when practical use-cases make it necessary. If it fits a bunch of (potential) users' needs, I do encourage you to push this idea forward. On the other hand: if we want to consider ease of use for many people as an important criterion, which we do, which one seems easier amongst the two following solutions? 1. Download T(A)ILS and burn it on a CD, then boot it when needed (possibly in a VM if you can afford it wrt. performance and security). 2. Replace your current OS with another one that supports SE Linux well enough to support the SE Linux enhanced sandbox described solution (examples needed), install the sandbox front-end program that does not exist yet, and setup the needed sandboxes for the apps that need to be Tor-ified and somehow isolated. Then you only need to never, ever confuse your nice sandboxed web browser with your other non-sandboxed one. As a T(A)ILS developer I am of course biased but #1 seems pretty much easier to me. Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr-fingerprint.asc | The impossible just takes a bit longer. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor + SELinux sandbox = leak proof without VM overhead?
On Sun, 29 Aug 2010 00:25 +0200, intrigeri intrig...@boum.org wrote: Hi, Gregory Maxwell wrote (22 Aug 2010 00:55:49 GMT) : 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. I doubt there is something like the best way of using Tor. One always needs to balance the risks vs. the efforts needed to get some protection against it. More practically speaking: there are use cases the Tor Browser Button is perfect for, but it cannot prevent every leakage of anonymity to local disks. Then come Tor-ified VM setups that protect users a bit more but still somehow rely on the host operating system. Then comes running a Tor-ified Live system such as T(A)ILS [1] on bare metal. Each situation has its best fit solution but I don't think one solution can be told to be best in any cases. [1] https://amnesia.boum.rog/ That would be '.org' :) BTW is there somewhere from where the CACert root certificate (or fingerprint) can be downloaded with protection from an SSL cert I already trust? The above link, once corrected, generates an SSL warning. GD -- http://www.fastmail.fm - Same, same, but different... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor + SELinux sandbox = leak proof without VM overhead?
On Sat, Aug 28, 2010 at 3:25 PM, intrigeri intrig...@boum.org wrote: ... Another cost mentioned by coderman was elevated privs for accelerated virtualization / para-virtualization. AFAIK VirtualBox does not need any special privileges (once the kernel part of the software is installed, and the modules/services loaded). the loading / configuring of kernel module part is one elevated task. route table changes / altering iptables rules and chains*, many other such things require elevated privileges. there are often host facilities to permit specific use of valid settings, and rsbac constraints, lots of other mitigation techniques... if you give up acceleration and do full softmmu / user only and constrained device emulation you can still have a guest / least privilege virtual machine, but the overhead is significant. fortunately fast virtio devices are become common across both userspace only and accelerated virtual machine implementations. i also like livecd as you mention, and qubes on live fedora is a nice setup, perhaps coupled with HTTPS-Fuse on-demand pre-caching file system overlays... many many different combinations and techniques to complement and fit a particular need. the limiting factor is time to explore them all and their relative strengths/weaknesses/trade-off's... http://unit.aist.go.jp/itri/knoppix/http-fuse/index-en.html http://qubes-os.org/Architecture.html * i call this out specifically because you need extend beyond the basic VirtualBox / Qemu / VMWare settings associated with the common bridge, nat, host-only network devices and implement host level routing protections; otherwise you're exposed to a number of potential side channel and other attacks listed in the FAQ and elsewhere. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor + SELinux sandbox = leak proof without VM overhead?
On Sat, Aug 28, 2010 at 3:25 PM, intrigeri intrig...@boum.org wrote: ... Please don't misunderstand me. I'm not a fan of VM-based solutions and pretty much prefer the bare-metal + Live OS approach, but I feel we need to consider their pros and cons in a more detailed way than discarding them on the assumption that their cost must be too high else we would push for their usage much more than we do. one last note, these are all complementary techniques. the SELinux effort early on was applied to VMWare virtual machine rules per instance on virtual disks and across network devices. improving the usability of such a configuration by deploying via livecd images supporting a wide range of hardware would also be a clear improvement for many users. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor + SELinux sandbox = leak proof without VM overhead?
On Sat, Aug 21, 2010 at 5:55 PM, Gregory Maxwell gmaxw...@gmail.com 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 majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor + SELinux sandbox = leak proof without VM overhead?
It certainly sounds interesting. Full VM environments not only cause system resource overhead, but maintenance overhead, too (that's always been my biggest gripe about them). F. Fox On 08/21/2010 05:55 PM, Gregory Maxwell wrote: (snip) 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. 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. (snip) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
