Re: [tor-bugs] #14322 [Core Tor/Torsocks]: torsocks fails to wrap setcap binaries

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs