Re: [PATCH 0/2] wait/ptrace: always assume __WALL if the child is traced

[Oleg Nesterov]

Forgot to say...

Another question is why PTRACE_TRACEME succeeds in this case. I guess
it is to late to change (break) the rules, but I never understood the
security checks. The comment above cap_ptrace_traceme() says:

	Determine whether another process may trace the current

and "another process" is parent. To me this looks strange, imo we should
determine whether the current may abuse its parent. So perhaps we could
change ptrace_traceme() to fail if

	current->parent_exec_id != parent->self_exec_id

?

But this too can break something. Although I can't imagine why the
child reaper or a PR_SET_CHILD_SUBREAPER process may want to trace
the reparented tasks.

On 10/20, Oleg Nesterov wrote:
>
> Damn. I simply do not know what should/can we do. From the change
> log:
>
> 	And I can only hope that this won't break something.
>
> yet this patch cc's -stable.
>
>
> Please see the changelog, but in short: this is not a kernel bug
> but unlikely we can fix all distributions, so I think we have to
> change the kernel.
>
> HOWEVER. With this change __WCLONE and __WALL have no effect for
> debugger, do_wait() works as if __WALL is set if the child (natural
> or not) is traced.
>
>
> Jan, Pedro, could you please confirm this won't break gdb? I tried
> to look into gdb-7.1, and at first glance gdb uses __WCLONE only
> because __WALL doesn't work on older kernels, iow it seems to me
> that gdb actually wants __WALL so this change should be fine.
>
>
> Any other ideas?
>
> Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/