TransPort, DNSPort, and pf
arma at mit.edu
Fri Dec 31 08:49:24 UTC 2010
On Fri, Dec 31, 2010 at 12:53:10AM -0600, Scott Bennett wrote:
> hellas# su _tor
> $ tor --verify-config
> Dec 30 23:33:41.799 [notice] Tor v0.2.2.17-alpha (git-dadd9608d2720368). This is experimental software. Do not rely on it for strong anonymity. (Running on FreeBSD i386)
> Dec 30 23:33:41.817 [warn] open("/dev/pf") failed: Permission denied
> Dec 30 23:33:41.818 [warn] Failed to parse/validate config: Unable to open /dev/pf for transparent proxy.
> Dec 30 23:33:41.818 [err] Reading config failed--see warnings above.
> My first question is, why does tor want to open /dev/pf when all packets
> from the internal network are redirected to tor on the loopback interface
Because Tor still needs to be able to learn where the original destination
was. Looks like it asks your OS that question through /dev/pf.
See connection_ap_get_original_destination() in src/or/connection_edge.c
> To get tor to stop complaining, I had to change the group of /dev/pf
> from wheel to _tor and change the device's permissions from 600 to 660.
Hm. I'm going you're on net or free bsd?
Quoting from get_pf_socket():
/* only works on OpenBSD */
pf = open("/dev/pf", O_RDONLY);
/* works on NetBSD and FreeBSD */
pf = open("/dev/pf", O_RDWR);
No idea why it would need read-write in particular on /dev/pf, but who
am I to answer the mysteries of BSD.
In any case, Tor expects you to start Tor as root if you want the pf
support to work, so it can open your /dev/pf correctly. That means you
should use the 'user' torrc option and Tor would drop privs once it's set
things up. (See the call to get_pf_socket() in options_act_reversible().)
> seems to me that neither should be necessary and that tor should not access
Do you know another way to do transparent proxying on BSD? I confess
that Linux's way (a getsockopt call) does look simpler. :)
More information about the tor-relays