linux-kernel - Re: execve-under-ptrace API bug (was Re: Ptrace documentation, draft #3)

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: <BANLkTikqRod7B30RCEf2V8Rq5zsz=QeZag@mail.gmail.com>
Date:	Mon, 30 May 2011 16:27:37 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	jan.kratochvil@...hat.com, oleg@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu
Subject: Re: execve-under-ptrace API bug (was Re: Ptrace documentation, draft #3)

On Mon, May 30, 2011 at 1:40 PM, Denys Vlasenko
<vda.linux@...glemail.com> wrote:
>>> I think the API needs fixing. Tracee must never disappear like that
>>> on execve (or in any other case). They must always deliver a
>>> WIFEXITED or WIFSIGNALED notification, allowing tracer to know
>>> that they are gone. We probably also need to document how are these
>>> "I died on execve" notifications are ordered wrt PTRACE_EVENT_EXEC
>>> stop in execve-ing thread.
>>
>> A problem is that by the time de-threading is in progress, it's
>> already too deep and there's no way back and the exec'ing thread has
>> to wait for completion in uninterruptible sleeps - ie. it expects
>> de-threading to finish in finite amount of time and to achieve that it
>> basically sends SIGKILL to all other threads.
>
> Which is fine. Can we make the death from this "internal SIGKILL"
> visible to the tracer of killed tracees?

Ok, let's take a deeper look at API needs. What we need to report, and when?

We have three kinds of threads at execve:
1. execve'ing thread,
2. leader, two cases: (2a) leader is still alive, (2b) leader has exited by now.
3. other threads.

(3) is the most simple: API should report death of these threads.
There is no need to ensure these death notifications are reported
before execve syscall exit is reported. They can be consumed
by tracer later.

(1) execve'ing thread is obviously alive. current kernel already
reports its execve success. The only thing we need to add is
a way to retrieve its former pid, so that tracer can drop
former pid's data, and also to cater for the "two execve's" case.
PTRACE_EVENT_EXEC seems to be a good place to do it.
Say, using GETEVENTMSG?

(2) is the most problematic. If leader is still alive, should
we report its death? This makes sense since if we do,
and if we ensure its death is always reported before
PTRACE_EVENT_EXEC, then the rule is pretty simple:
at PTRACE_EVENT_EXEC, leader is always reported dead.

However, I don't see why we _must_ do it this way.
The life of tracer is not that much worse if at
PTRACE_EVENT_EXEC leader which is still alive
is simply "supplanted" by the execve'ed process.

We definitely must ensure, though, that if leader races with
execve'ing thread and enters exit(2), its death is never reported
*after* PTRACE_EVENT_EXEC - that'd confuse the tracer for sure!
Process which has exited but is still alive?! Not good!

-- 
vda
--
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/