On 2013-06-19 10:44:39 -0700, Kees Cook wrote: > This is what /etc/sysctl.d/ is for: changing defaults.
Yes, but IMHO, the default is not fine (see below). > 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. If a ssh is running, then there's probably a ssh-agent too, and even if ptrace is blocked, the attacker can start a new SSH connection anyway. Also, I think that a trap is too easy to construct once the attacker gained a shell access, in particular due to the fact that the user doesn't normally know that his account has been compromised. If you really fear such attacks via buggy applications, running such applications like Firefox under a different user[*] (or some other solution?) should be much more secure than the very minor ptrace protection feature. [*] This reminds me the Android security model, where each application runs under a unique user id. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
