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: <20110530134925.GB4739@redhat.com>
Date:	Mon, 30 May 2011 15:49:25 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Tejun Heo <tj@...nel.org>, jan.kratochvil@...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 05/30, Denys Vlasenko wrote:
>
> Consider how strace tracks its tracees. Currently, it remembers
> their pids - sometimes by remembering clone's return values!
> This is hopelessly broken wrt pid namespaces.

Yes. Unless the tracer lives in the same namespace it can't use
RAX as the pid. This return value is only makes sense inside the
tracee's namespace.

There is another problem, tracehook_report_clone_complete()
sets PTRACE_GETEVENTMSG == global_pid. IOW, this value can't
be used unless the tracer runs in the root namespace.

> So I looked at removing all pid tracking from strace,

I am not sure... but you certainly know better what strace
can/should do.

> The idea is that strace can simply create a new tracee's data
> structure when it sees a new, never before seen pid popping up
> from waitpid

This can probably work for strace. Note that this means strace
can't detach all tracees gracefully, it simply doesn't know them
all. But probably strace doesn't need this.

> This works (I have a patch against a somewhat older strace),
> but now in light of this "interesting" execve-under-ptrace
> behavior it appears to have a flaw: all threads except the
> execve'ing one disappear without any notification to strace,
> therefore strace doesn't know which tracee data ("struct tcb"
> in strace-speak) need to be dropped!

I think there is no choice currently, strace should remember tgid.

> I think the API needs fixing.

ptrace() should not be pid/thread based ;) But this is offtopic now.

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/