[tor-bugs] #18356 [Obfsproxy]: obfs4proxy cannot bind to <1024 port with systemd hardened service unit

[Tor Bug Tracker & Wiki]

#18356: obfs4proxy cannot bind to <1024 port with systemd hardened service unit
-----------------------------+-----------------------------------------
     Reporter:  irregulator  |      Owner:  asn
         Type:  defect       |     Status:  new
     Priority:  Medium       |  Milestone:
    Component:  Obfsproxy    |    Version:  Tor: 0.2.7.6
     Severity:  Normal       |   Keywords:  obfs4proxy, systemd, jessie
Actual Points:               |  Parent ID:
       Points:               |    Sponsor:
-----------------------------+-----------------------------------------
 Hi,

 I was running an obfs4proxy Debian Wheezy bridge with such configuration
 in torrc:


 {{{
 ServerTransportListenAddr obfs4 0.0.0.0:443
 }}}

 When I dist-upgraded to Debian Jessie, obfs4proxy could not bind to :443
 any more, while tor logs had such messages:


 {{{
 Feb 21 22:51:09.000 [warn] Server managed proxy encountered a method
 error. (obfs4 listen tcp 0.0.0.0:443: bind: permission denied)
 Feb 21 22:51:09.000 [warn] Managed proxy at '/usr/bin/obfs4proxy' failed
 the configuration protocol and will be destroyed.
 }}}

 Mind that I have already set the appropriate capability to the obfs4proxy
 binary:

 {{{
 getcap /usr/bin/obfs4proxy
 /usr/bin/obfs4proxy = cap_net_bind_service+ep
 }}}

 I took some time moving things around and I think the problem resides on
 the systemd service unit:
 https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in and
 specifically the option introduced in
 b4170421cc58d8c57254f4224ba259e817f48869 .

 {{{
 NoNewPrivileges=yes
 }}}

 I assume so because flipping 'NoNewPrivileges=no' results in obfs4proxy
 binding to 443. Also, 'PR_SET_NO_NEW_PRIVS' section in 'man 2 prctl'
 implies so:

 {{{
 PR_SET_NO_NEW_PRIVS (since Linux 3.5)
               Set  the  calling  process's  no_new_privs  bit to the value
 in arg2.  With
               no_new_privs set to 1, execve(2) promises not to  grant
 privileges  to  do
               anything  that  could  not  have  been done without the
 execve(2) call (for
               example, rendering the set-user-ID and set-group-ID
 permission  bits,  and
               file  capabilities  non-functional).   Once  set, this bit
 cannot be unset.
               The setting of this bit is inherited by children  created
 by  fork(2)  and
               clone(2), and preserved across execve(2).

               For   more   information,   see   the   kernel   source
 file   Documenta‐
               tion/prctl/no_new_privs.txt.
 }}}

 I understand that 'NoNewPrivileges=no' is a system security drawback but I
 also consider a regression to not be able to bind obfs4proxy to ports
 <1024. Could we find a middle ground?


 If that helps, I'm running:

 {{{
 tor: 0.2.7.6-1~d80.jessie+1
 deb.torproject.org/torproject.org/ jessie/main amd64 Packages

 obfs4proxy: 0.0.4-1~tpo1
 deb.torproject.org/torproject.org/ obfs4proxy/main amd64 Packages
 }}}

 Also:

 {{{
 cat /etc/debian_version
 8.3
 cat /proc/version
 Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version
 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17)
 }}}

 Thanks for your work.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18356>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online