[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#712740: the default is fine



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 <vincent@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)


Reply to: