[tor-bugs] #14322 [Core Tor/Torsocks]: torsocks fails to wrap setcap binaries
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sat Jun 11 08:52:43 UTC 2016
#14322: torsocks fails to wrap setcap binaries
-----------------------------------------------+-------------------------
Reporter: cypherpunks | Owner: dgoulet
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Core Tor/Torsocks | Version:
Severity: Normal | Resolution:
Keywords: setcap setuid LD_PRELOAD torsocks | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-----------------------------------------------+-------------------------
Changes (by cypherpunks):
* severity: => Normal
Comment:
It used to be possible to start a process with `CLONE_STOPPED` which would
cause it to start as if it were immediately given `SIGSTOP` so it would
not be able to make even one syscall. From then, it would be possible to
check in `/proc` if `LD_PRELOAD` is still set in `environ`, or if
`AT_SECURE` is set in `auxv`. Unfortunately that capability was removed
from Linux's `clone()` behavior from 2.6.38 on.
The problem with checking for setuid, setgid, and capabilities is that
there are a few other ways that secureexec can be enabled, such as through
SELinux, RSBAC, grsecurity's RBAC, etc. A robust solution would be able to
detect if the process has or would have `AT_SECURE` in the first place,
rather than just checking for a list of blacklisted filesystem attributes.
Perhaps we could ask for the old `CLONE_STOPPED` behavior to be put back.
I believe it was removed due to lack of use, but this may be a
sufficiently compelling reason for it to be added back. It really is a
very simple feature, so there'd likely be no objection (except perhaps the
fact that the bit has been re-used for `CLONE_NEWCGROUP` as of 4.6, but
that's easy to work around). It has other potential debugging uses as
well.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14322#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list