debian obfsproxies can't advertise ports under 1024

We don't have (m)any obfsproxies running on port 443. That's a shame.

But if you're on debian and want to follow our instructions (https://www.torproject.org/projects/obfsproxy-debian-instructions), even if you know how to set up port forwarding, there's no way for your Tor to advertise that your obfsproxy is listening on a low-numbered port.

One option is for Tor to launch obfsproxy as root before Tor drops privs, and then obfsproxy binds its low-numbered port and then drops privs too. That sounds awful.

Another option is to complexify ServerTransportListenAddr, or add a new config option like it, so we can tell Tor what address to pretend obfsproxy listens on. That sounds less awful but still not great.

Other options? It would be ideal if the Tor and obfsproxy debs could somehow do this themselves, since an "add this line to your iptables" component in our instructions places it out of reach of most users.

changed milestone to %Tor: unspecified

added component::core tor/tor low-ports milestone::Tor: unspecified owner::asn priority::medium privileges review-group-34 severity::normal status::new tor-bridge tor-pt type::defect labels

You can grant priviledges to do so via setcap. (included in libcap2-bin) setcap 'cap_net_bind_service=+ep' /path/to/obfsproxy

After granting this capability you are able to run obfsproxy with user rights on ports <1024

http://www.kernel.org/doc/man-pages/online/pages/man7/capabilities.7.html

Trac:
Username: flaushy

Trac:
Username: cwt96
Component: Tor to Obfsproxy
Owner: N/A to asn

Trac:
Component: Obfsproxy to Tor

Replying to flaushy:

You can grant priviledges to do so via setcap. (included in libcap2-bin) setcap 'cap_net_bind_service=+ep' /path/to/obfsproxy

After granting this capability you are able to run obfsproxy with user rights on ports <1024

This is not working for me, maybe because obfsproxy is now (version 0.2.1) a (Python) script (see caveat 2 in the first answer on http://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-1024-on-l ).

Indeed, with a downgrade of obfsproxy to 0.1.4, it works. (But obfs3 would be missing).

Trac:
Username: torvlnt33r
Cc: asn, mo, weasel to asn, mo, weasel, torvlnt33r@fastmail.fm

Replying to torvlnt33r:

Replying to flaushy:

You can grant priviledges to do so via setcap. (included in libcap2-bin) setcap 'cap_net_bind_service=+ep' /path/to/obfsproxy

After granting this capability you are able to run obfsproxy with user rights on ports <1024

This is not working for me, maybe because obfsproxy is now (version 0.2.1) a (Python) script (see caveat 2 in the first answer on http://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-1024-on-l ).

Ok, it works if you make a copy of the script interpreter and give it the capabilities, as described as workaround in above reference.

On my system, python is a symbolic link to /usr/bin/python2.7. So: cp /usr/bin/python2.7 /path/to/copy/of/python2.7 setcap 'cap_net_bind_service=+ep' /path/to/copy/of/python2.7

and add the interpreter into the ServerTransportPlugin line in torrc: ServerTransportPlugin obfs2,obfs3 exec /path/to/copy/of/python2.7 /usr/bin/obfsproxy managed

Trac:
Username: torvlnt33r

The setcap solution requires the operator to run the setcap command as root, right? I guess that's equally "bad" (from the point of view of a non-technical operator) to an iptables command that redirects traffic from the low order port to the obfsproxy port.

arma's ideas still stand (because they don't require operator intervention) but they both still sound awful :(

Actually, my option two doesn't sound so bad. It's basically a config option to specify what port Tor should advertise, as opposed to what port Tor should tell obfsproxy to listen on.

Hey, another (bad but not horrible) option is to for Tor to grow a new "redirect" conn type, which it opens when it starts, and which funnels bytes from incoming conns to the specified destination port, maybe using our 'linked conns' notion. That would be sort of like running the iptables rule, but more portable and less scary for novice operators.

Trac:
Cc: asn, mo, weasel, torvlnt33r@fastmail.fm to asn, mo, weasel, torvlnt33r@fastmail.fm, mttp

Can the difference between options 2 and 3 be clarified? I think I read option 2 and I thought it was describing the same design as option 3, but apparently not if option 3 is a distinct option.

Replying to cypherpunks:

Can the difference between options 2 and 3 be clarified? I think I read option 2 and I thought it was describing the same design as option 3, but apparently not if option 3 is a distinct option.

Seems like pretty much the same idea to me. One comment describes the torrc side, the other describes how it could work using Tor's linked conns.

#8195 (moved) might also be a step forward. It uses Linux capabilities(7) to let Tor bind to low listening ports even after it has dropped privs. David told me that Linux capabilities also do inheritance, so it might be possible for our PT processes to inherit this capability themselves.

Trac:
Cc: asn, mo, weasel, torvlnt33r@fastmail.fm, mttp to asn, mo, weasel, torvlnt33r@fastmail.fm, mttp, dgoulet

Trac:
Cc: asn, mo, weasel, torvlnt33r@fastmail.fm, mttp, dgoulet to asn, mo, weasel, torvlnt33r@fastmail.fm, mttp, dgoulet, yawning

Replying to asn:

#8195 (moved) might also be a step forward. It uses Linux capabilities(7) to let Tor bind to low listening ports even after it has dropped privs. David told me that Linux capabilities also do inheritance, so it might be possible for our PT processes to inherit this capability themselves.

Yawning posted some updates on this from the dev meeting:

At the dev meeting I was talking to dgoulet about having tor do the
appropriate work to preserve the CAP_NET_BIND_SERVICE when dropping root
so all PTs transparently get this capability.

He mentioned difficulties with our python PTs, probably because the
ServerTransportPlugin line was pointing directly at the script and it
was getting invoked via the #! handler in the kernel.  It may be
possible that this "just works" if the ServerTransportPlugin line
pointed at the python interpreter instead, but if it does not, this will
probably require a kernel patch, that won't ever get accepted upstream.

from https://lists.torproject.org/pipermail/tor-dev/2014-July/007139.html

And for completeness, this is the line I'm using in my bridge to make obfs3 reachable on port 443: # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 25429 where the actual port of obfs3 is 25429.

arma pointed out this afternoon that dgoulet's patches for #8195 (moved) might be applicable to fixing this. It would need testing for execing PT ServerTransportPlugin lines for both Go and Python PTs (with /usr/bin/python or via the #! line, as asn pointed out above).

Trac:
Status: new to needs_review

In the bright new obfs4proxy feature, setcaping the obfs4proxy binary behaves as expected, so any/all of:

• #8195 (moved) assuming tor starts with sufficiently elevated privileges.
• The admin manually setcaping the obfs4proxy binary.
• The package automagically handling this somehow (don't ask me how).

will solve this for obfs2/3/4. FTE/ScrambleSuit still use the old python codebase so those require further investigation. Personally, I don't view manually calling setcap on installation/update as a huge hassle, but then again my bridge deployment procedure consists of scping the binary over, and running a shell script, so I'm probably not the person to make decisions here.

The fact that obfs4proxy works with setcap is also documented in the README.md file, so we're in a better situation than previously, and when we do our bridge deployment documentation revamp, we can also highlight this there.

setcapping the binary would allow any user to listen on any low port using the binary. I don't think it's a good general purpose solution for a distribution.