ptrace_scope now set to 0 by default

[Ludovic Courtès]

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’.