Re: Jailed/sandboxed/chrooted applications

[7v5w7go9ub0o <7v5w7go9ub0o@xxxxxxxxx>]

Adlesshaven wrote:
> Does anyone here jail, sandbox or chroot the applications they use 
> with Tor?

yep.

1. Separate, individual (GRSecurity-hardened) jails on Linux for
Thunderbird, Opera, and TOR itself.

2. Opera connects to TOR via polipo - which is jailed in a "common"
jail; and Thunderbird connects to tor via Socat - which is also jailed
in that common jail (as are lftp and filezilla, which occasionally use
TOR, or go direct).

I jail TOR because it may be attacked directly from the WAN; I
separately jail the tools connecting to TOR (socat and polipo) because
they occasionally connect to the WAN directly. Because they are
highly targeted, I figure that browsers and mail clients ought to be
individually jailed as a general principle.


> I have been trying to adapt the Wiki's transparent proxy 
> recommendations to a FreeBSD jail for the last couple weeks with no 
> luck.

Do FreeBSD jails automatically provide a different address (e.g.
127.0.0.2)? If so, you may need to check the proxy addresses.


What is the
> best way to isolate applications completely for use with Tor?


IMHO, In order of priority:

1. Separate machine on LAN.
   or
2. Separate virtual machines on hardened (e.g. bsds; hardened linux) box.
   or
3. Jails
   or
4. none of the above, but running each application as an individual,
privilege-less user that can not read beyond its own home directory. So
if user "tor:tor" is compromised, it can only read files on /home/tor
and not beyond.

(obviously, item 4 actually applies to each of the three preceding items
as well :-) )

(obviously, most users choose alternative 5 ....... a single user runs a
host of programs, including browser, tor, mail, etc.)

HTH

p.s.

Don't know what a transparent proxy is. from wikipedia: "Transparent and
non-transparent proxy server

The term "transparent proxy" is most often used incorrectly to mean
"intercepting proxy" (because the client does not need to configure a
proxy and cannot directly detect that its requests are being proxied).
Transparent proxies can be implemented using Cisco's WCCP (Web Cache
Control Protocol). This proprietary protocol resides on the router and
is configured from the cache, allowing the cache to determine what ports
and traffic is sent to it via transparent redirection from the router.
This redirection can occur in one of two ways: GRE Tunneling (OSI Layer
3) or MAC rewrites (OSI Layer 2).

However, RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) offers
different definitions:
"A 'transparent proxy' is a proxy that does not modify the request or
response beyond what is required for proxy authentication and
identification".
"A 'non-transparent proxy' is a proxy that modifies the request or
response in order to provide some added service to the user agent, such
as group annotation services, media type transformation, protocol
reduction, or anonymity filtering".