linux-kernel - PTRACE_SEIZE/INTERRUPT: [RFC] Proposal for ptrace improvements

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: <20110307150803.GA16521@redhat.com>
Date:	Mon, 7 Mar 2011 16:08:03 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Roland McGrath <roland@...hat.com>, jan.kratochvil@...hat.com,
	Denys Vlasenko <vda.linux@...glemail.com>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: PTRACE_SEIZE/INTERRUPT: [RFC] Proposal for ptrace improvements

On 03/01, Tejun Heo wrote:
>
> P4. PTRACE_SEIZE

Now that we more or less agree with Tejun's ideas, I'd like to
discuss the "cosmetic" issues. But first of all let me repeat,
I do not have the strong opinion, I agree with everything in
advance.

The only really important thing (to me) is that ATTACH/INTERRUPT do
not induce SIGSTOP but force the tracee to trap (if needed), this
looks obviously good.

> I don't think it's a good idea to attach without putting the tracee
> into TASK_TRACED.

Agreed.

Jan, do you have any reason for attach-without-putting-into-TRACED?

> I can't see much, if any, benefit in implementing ATTACH and INTERRUPT
> separately.

I can ;) Although the benefit is minor.

First of all, the single request can "hide" the user-space bugs.
For example, gdb is very complex, suppose that it uses the wrong
pid during the debugging session. In this case it would be nice if
the kernel returns the error instead of attaching to the wrong
thread.

Of course, gdb can use the wrong pid during attach as well, but
this is less likely. Sometimes gdb doesn't even know that some
thread has gone away, suppose that it blindly does PTRACE_SEIZE
after that and this pid was alredy reused.

Or. Suppose that gdb tries to attach the whole thread group (it
always does this), and attaches to the same thread twice by mistake.
The kernel can help in this case and return the error.

And I think there are other reasons. Say, suppose we want to add
the options for ATTACH/INTERRUPT. Right now I do not see the need,
but who knows.

And. Error codes. Currently ptrace_check_attach() can only return
ESRCH, this doesn't look very convenient. If we add INTERRUPT we
can make this more informative. The same for PTRACE_ATTACH, btw.
EPERM should mean security error, nothing else. IOW, error codes
should be different depending on attach/interrupt mode.

In any case. Jan, Denys, what do you think? Your opinion is more
important, I can only speculate.

Final note... Previously I thought that we should not (I meant, can
not) change the current behaviour of PTRACE_O_TRACECLONE/etc which
sends SIGSTOP during the auto-attach. Now I am not sure, probably
we can avoid SIGSTOP if the forking task was PTRACE_SEIZE'ed. IOW,
perhaps the new ATTACH can have other "side effects". But, otoh,
this can complicate the transition to the new requests. Say, you
can't simply change strace to use PTRACE_SEIZE without auditing
the "-f" code.

And. This is off-topic, but we can also add PTRACE_DETACH_XXX which
does not require the stopped tracee. strace certainly needs it,
although INTERRUPT can solve most of the problems.

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/