linux-kernel - Re: Race in ptrace.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4352991a1002111239m681107f8g9e3802daf7ab706b@mail.gmail.com>
Date:	Thu, 11 Feb 2010 12:39:09 -0800
From:	Salman Qazi <sqazi@...gle.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	taviso@...gle.com, Roland Dreier <rolandd@...co.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Race in ptrace.

On Thu, Feb 11, 2010 at 12:10 PM, Oleg Nesterov <oleg@...hat.com> wrote:
> On 02/11, Salman Qazi wrote:
>>
>> I understand what it does.  But, why is it the right thing to do?
>
> Oh. Let's not discuss the current API. Nobody thinks it is great,
> but we can't change it.
>
> But,
>
>> From the user's perspective, why should the task become untraced if we
>> use ptrace to deliver the signal?
>
> The task does not become untraced. The tracer (in your test-case)
> explicitly asks the tracee to respect SIGSTOP and stop.
>
>> Doesn't this make it impossible to
>> intercept and control which signals are sent to a traced task?
>
> Why? The tracee reports all signals. If the tracer does
> ptrace(PTRACE_WHATEVER, SIGXXX) surely it knows SIGXXX is sent to
> tracee.
>
>

The ptrace syscall fails, as the child is running and so we are unable
to restart the child.  I suppose it is not accurate to say "impossible
to intercept" if it eventually works.  But, it's an unpleasant
behaviour.  How do you distinguish between this race and the child
suddenly becoming untraced or dying?

What I don't agree with is that when we send SIGCONT later with
"kill", we wake up the child at all.  It may make sense to someone who
has access to the kernel source code, but from a user's point of view
this is a surprise.  The signal is intercepted and should not have an
effect on the child.

>
>
> In any case. This is how ptrace currently works, there is no race
> and the patch is not needed (in fact it is very wrong, but this
> soesn't matter).
>
> Do you agree?

I agree that the patch is wrong because of the reasons you mentioned
earlier.  But I think there is an issue here.  It's hard to say what
it is supposed to do, but I can certainly see it being more useful
this behaviour wasn't there.  Thanks for your time and attention on
this matter.

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