This is what /etc/sysctl.d/ is for: changing defaults. There are, in fact, real protections with this change. Namely, the delay of attack expansion. Take the case of a server being attacked. If there are ssh connections left open from that machine, without the ptrace restrictions, an attacker can trivially jump down the existing connections, expanding the scope of the attack. With the restrictions, they must construct a trap for the user to fall into (.bashrc, etc) and wait for re-establishment of connections before credential theft can occur. The same is true for various desktop scenarios. Full user access is game-over from a technical perspective, but there are real-world situations where this restriction is an improvement.
Debugging applications, by default, will not be able to attach to existing running processes, that is certainly a down-side to the restriction. However, running processes under a debugger is still possible, and doing live debugging as root is still possible. The root user using "strace -p" is a very common sysadmin workflow, and it's affected by this restriction. Ubuntu carries patches to gdb, strace, and ltrace that contain more helpful error messages, so maybe Debian could carry those as well. Unfortunately, many upstreams have repeatedly refused to use the "dumpable" flag like ssh-agent does (e.g. gpg), so it won't work as a general solution. Blocking sibling ptracing also improves container security. This is a good default, and if specific system owners don't want it enabled, they can choose to turn it off in /etc/sysctl.d/, just like other things. -Kees -- Kees Cook @debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
