linux-kernel - Re: [PATCH v3] Make PTRACE_SEIZE set ptrace options specified in 'data'

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]

Date:	Sat, 10 Sep 2011 16:36:36 +0100
From:	Pedro Alves <pedro@...esourcery.com>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>, Tejun Heo <tj@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] Make PTRACE_SEIZE set ptrace options specified in 'data'

On Saturday 10 September 2011 13:12:38, Pedro Alves wrote:

> (just-options-on-SEIZE scares me in terms of future expansion,
> as it assumes only bitflags will ever be necessary.)

The more I think of this, the more I think we could do this
some other way --- why don't we allow setting the default
options _on the ptracer_, and then tracee's inherit those
options from the ptracer-set-of-default-options if their
parent is not currently ptraced by own tracer?  That is, you'd make
the ptracer set options on itself:

options = PTRACE_O_TRACESYSGOOD | PTRACE_O_TRACECLONE|FORK|VFORK|EXEC ...;
ptrace(PTRACE_SETOPTIONS, gettid(), 0, options);

And then, in all of

 ptrace(PTRACE_ATTACH, foo_pid, 0, 0);
 ptrace(PTRACE_TRACEME, 0, 0, 0);
 ptrace(PTRACE_SEIZE, foo_pid, 0, 0);

you'd end up with the tracee already with your chosen options set.

Clones, vforks and forks that are auto-attached would still inherit their
options from their parent, just like today.

Some pro points:

- works for PTRACE_ATTACH AND PTRACE_TRACEME too.

- most ptracers on earth will only need to set options once.

- backwards compatible.  The "default ptrace options" default
to 0, so old tracers on new kernels will still behave the same.

- future proof.  If some other PTRACE_SET_NEAT_OPTION ptrace
command appears in the future, we can make it work the same
way, instead of getting stuck with PTRACE_SEIZE's `data'
already being taken...

- if ptrace(PTRACE_SETOPTIONS, gettid(), 0, 0) works, then
we can stop gdb (and probably other tracers) from forking a new
child just to check if PTRACE_O_TRACEFOO works before actually
attaching/spawning the process of interest.
(see code around linux_supports_tracefork_flag at
<http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/linux-nat.c?rev=1.215&content-type=text/x-cvsweb-markup&cvsroot=src>)

Cons:

- is there any real con?

Note the default ptrace options would _not_ conflict with
the ptracer's own ptrace options in case the ptracer itself
is being ptraced.

WDYT?

-- 
Pedro Alves
--
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/