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:	Tue, 13 Sep 2011 09:45:00 +0200
From:	"Indan Zupancic" <indan@....nu>
To:	"Pedro Alves" <pedro@...esourcery.com>
Cc:	"Denys Vlasenko" <vda.linux@...glemail.com>,
	"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'

Hello,

On Sat, September 10, 2011 17:36, Pedro Alves wrote:
> 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);

Please just use a zero pid to set options on yourself, that's easier for
everyone.


> 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>)

The forking a new child just to check the option is needed because aparently
some old ptrace version didn't return an error for unknown options (according
to the comment in that code), so trying it out is the only reliable way of
being sure if options are supported or not. Otherwise no extra forking would
be needed anyway.

> 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?

I agree that this would probably be better than setting options at SEIZE
time.

Greetings,

Indan


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