[tor-bugs] #14322 [Torsocks]: torsocks fails to wrap setcap binaries

[Tor Bug Tracker & Wiki]

#14322: torsocks fails to wrap setcap binaries
---------------------------+-----------------------------------------------
     Reporter:             |      Owner:  dgoulet
  cypherpunks              |     Status:  new
         Type:  defect     |  Milestone:
     Priority:  normal     |    Version:
    Component:  Torsocks   |   Keywords:  setcap setuid LD_PRELOAD torsocks
   Resolution:             |  Parent ID:
Actual Points:             |
       Points:             |
---------------------------+-----------------------------------------------

Comment (by yawning):

 Replying to [comment:2 cypherpunks]:
 > I apologize in advance for everything wrong with this code, but how
 about wrapping the entire execve call to perform checks before executing
 it?
 >
 > https://gist.github.com/0xcaca0/037ab1f7bf4ac290e60a (this bit of code
 needs *serious* work, purely a PoC, good luck getting it to even compile,
 etc)

 Hmmm, after some more thought, there's two issues here, depending on how
 torsocks is invoked/used:
  * Invoked as `torsocks cmd`, the current shell doesn't have the torsocks
 wrapper loaded, so wrapping `execve` and friends in libtorsocks does
 absolutely nothing.  We need to use something like my helper (or setcap if
 we make that a dependency) to check the capabilities of the file before
 launching it, unless we always want to spawn a wrapped subshell instance.
 (Do we care about "something called setcap between when we checked the
 capabilities on a file and when we actually execve()-ed it"?  If so always
 using a wrapped subshell may be the best option.)
  * Invoked as `. torsocks on`, we need to wrap `execve` and friends, so
 that child processes don't end up having the kernel remove `LD_PRELOAD`.

 So, both?  The helper can be linked against libtorsocks.so to reduce code
 duplication as well since we need to include the check there...

 Note: On more recent Linuxes (>= 3.5), it's possible to skip the
 libtorsocks.so suid/sgid/capabilities checks entirely, via `prctl()` with
 `PR_SET_NO_NEW_PRIVS`.  The kernel will then entirely ignore capabilities,
 suid, sgid permanently for the current process and all of it's future
 children.  This would break torified `sudo`/`su`/etc though... (Prior
 versions require the process to have `CAP_SETPCAP` to clear the bounding
 set....).

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