While debugging an elfutils build failure, I discovered a Linux restriction that I had been papering over using sudo for some time.
Starting from Linux 3.4 or so, the default policy is to disallow users to attach (with PTRACE_ATTACH) to their own processes. Only CAP_SYS_PTRACE processes (i.e., root) or the target process’ parents can attach. This is “for security reasons”, as noted in Linux’s Yama.txt: ptrace_scope: As Linux grows in popularity, it will become a larger target for malware. One particularly troubling weakness of the Linux process interfaces is that a single user is able to examine the memory and running state of any of their processes. For example, if one application (e.g. Pidgin) was compromised, it would be possible for an attacker to attach to other running processes (e.g. Firefox, SSH sessions, GPG agent, etc) to extract additional credentials and continue to expand the scope of their attack without resorting to user-assisted phishing. This is not a theoretical problem. SSH session hijacking (http://www.storm.net.nz/projects/7) and arbitrary code injection (http://c-skills.blogspot.com/2007/05/injectso.html) attacks already exist and remain possible if ptrace is allowed to operate as before. Since ptrace is not commonly used by non-developers and non-admins, system builders should be allowed the option to disable this debugging system. For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to specifically disallow such ptrace attachment (e.g. ssh-agent), but many do not. A more general solution is to only allow ptrace directly from a parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID" still work as root). But this sounds a little bit silly: it imposes a serious restriction on what users can do (they can no longer attach gdb and such to their own processes!) while providing dubious security improvements. First, we’re talking about attackers who have a user shell anyway, so one could argue that PTRACE_ATTACH is just one option among many, many others the attacker could use. Second, the “right fix” is known: security-sensitive applications such as agent can explicitly ask not be to attachable. There seem to be quite a few people on the intertubes who question this security policy along these lines. See for instance: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712740 https://bugzilla.redhat.com/show_bug.cgi?id=1210966 So commit b158f1d restores the original PTRACE_ATTACH behavior by default. If you think this is wrong, let’s discuss it! :-) Thanks, Ludo’.