Re: 2.4+ptrace exploit fix breaks root's ability to strace

[Russell King <rmk@arm.linux.org.uk>]

On Sat, Mar 22, 2003 at 04:28:05PM +0100, Arjan van de Ven wrote:
> 
> > --- orig/kernel/ptrace.c	Wed Mar 19 15:54:45 2003
> > +++ linux/kernel/ptrace.c	Sat Mar 22 10:14:01 2003
> > @@ -22,7 +22,7 @@
> >  int ptrace_check_attach(struct task_struct *child, int kill)
> >  {
> >  	mb();
> > -	if (!is_dumpable(child))
> > +	if (!is_dumpable(child) && !(child->ptrace & PT_PTRACE_CAP))
> >  		return -EPERM;
> >  
> >  	if (!(child->ptrace & PT_PTRACED))
> 
> this sounds really wrong; the child says it doesn't want to be ptraced
> and now you allow it anyway. I think the problem is more that the child
> isn't dumpable.... checking why

ptrace has always explicitly allowed a process with the CAP_SYS_PTRACE
capability to ptrace a task which isn't dumpable.  With the ptrace "fix"
in place, you can attach to a non-dumpable thread:

int ptrace_attach(struct task_struct *task)
{
	...
-       if (!task->mm->dumpable && !capable(CAP_SYS_PTRACE))
+       if (!is_dumpable(task) && !capable(CAP_SYS_PTRACE))
                goto bad;
}

but you can't do anything with it (not even detach from it):

int ptrace_check_attach(struct task_struct *child, int kill)
{
	...
+       if (!is_dumpable(child))
+               return -EPERM;
}

So, we went from being able to ptrace daemons as root, to being able to
attach daemons and then being unable to do anything with them, even if
you're root (or have the CAP_SYS_PTRACE capability).  I think this
behaviour is getting on for being described as "insane" 8) and is
clearly wrong.

Note that processes become "undumpable" as soon as they starts playing
with its [GU]IDs (via setre[gu]id, set[gu]id, set_res[gu]id, setfs[ug]id.)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html