Update ptrace instructions for linux systems

[dosy4ev]

Using setcap to enable ptrace calls for reptyr is more secure way than system wide configuration.

[nelhage]

Thanks for the PR! Unfortunately, this change has the effect of allowing reptyr to attach to any process on the system; CAP_SYS_PTRACE allows tracing any process.

I tested on a development machine, and with that fscap I was able to attach (with -s) to a root shell, confirming that this advice opens up a privilege escalation vulnerability. We could in principle implement permission checking in reptyr itself to make this safe, but I'm not comfortable maintaining that level of attack surface in reptyr; setuid binaries are notoriously difficult to write safely, and CAP_SYS_PTRACE is effectively as powerful as setuid root, since you can ptrace a uid 0 binary and gain root that way.

[kees]

Would something like this help? (Totally untested...)

https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=yama/devel/any_tracee

Basically, a CAP_SYS_PTRACE tracer could call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, PR_SET_PTRACER_ANY_TRACEE) and then drop CAP_SYS_PTRACE, and be left with the privileges to bypass the ptrace ancestry requirements.

[nelhage]

Huh, that's an interesting proposal. A few thoughts here:

• I still don't like the idea of encouraging more fscap CAP_SYS_PTRACE binaries. Even though reptyr would presumably drop the priv before any code in main() looks at user input, as we're all familiar with, there's still a lot of room for vulnerability in libc setup etc. Or course, that's mostly shared with every other setuid binary on the system, so we perhaps aren't making the world worse, except insofar as reptyr may lack hardening if distributions have been building it under the assumption that it doesn't contain attack surface. I'm not sure if that's the case. Basically I guess the tl;dr is "I'm wary of adding a new (effectively) setuid binary, as well as of being personally responsible for one"
• The resulting privilege model is … weird. With YAMA enabled, but reptyr installed and CAP_SYS_PTRACE, you can't trace arbitrary processes with your uid, but you can steal their stdio. For shells that's just as good, and for other processes it's much more complex and hard to reason about. It's probably a narrower set of capabilities than straight-up disabling YAMA ptrace restrictions (as the current doc recommend), but it's also much harder to reason about in a way I don't love.