[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #14322 [Torsocks]: torsocks fails to wrap setcap binaries
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs