>> Try ftp.netbsd.org:/pub/NetBSD/misc/mouse/sigkill.c on your favorite
>> system.
> Hmmm!  Thanks for that!

No problem.

> SunOS 5.6 sun4m

> p2 attaching to 20058
> p2 PTRACE_ATTACH failed: No such process

How odd.  Looks as though their PT_ATTACH (the message needs fixing; I
guess I fixed the code and forgot to fix the printf) doesn't work, or
at least doesn't match the NetBSD documented behaviour.

> Looks like the bug I feared is real all right.

Well...I disagree with your characterization of it as a bug, but yes,
the behaviour you anticipated is real.

> Traditionally ptrace() didn't work for non-parent processes, and for
> processes which were not started with the intention of being
> processed, which is why there is a PT_TRACE_ME request in the first
> place.  Now we have the ability to ptrace() unrelated processes using
> PT_ATTACH, and that seems to be where this bug must have crept in.

I see no reason to think this has anything to do with PT_ATTACH, either
in the current implementation or historically.

I've built a variant that doesn't depend on PT_ATTACH, for you to try
on a pre-PT_ATTACH system if/when you get a chance to.  Since I see no
particular value in the version with PT_ATTACH vs this one, I've just
replaced ftp.netbsd.org:/pub/NetBSD/misc/mouse/sigkill.c with the new
version.  (I still see the traced-continue-after-kill behaviour.)

> I would hope your program would fail to restart p1 since you don't
> use PT_TRACE_ME and there is no PT_ATTACH

Well, with no PT_ATTACH it won't even compile, so discussing whether it
will restart p1 is rather silly.

> This apparent PT_ATTACH security bug

I still see no reason to think it has anything whatever to do with
PT_ATTACH.

> Unless I'm missing something PT_ATTACH and the buggy SIGKILL
> behaviour allows a set of co-operating rogues could keep each other
> going just so long as at least one of them got a decent timeslice
> after any of the other ones it's waching was SIGKILLed and could then
> get in at least one ptrace() call to restart one other before they
> all got SIGKILLed (and around they'd go restarting each other as fast
> as you could try to kill them).

You're missing something: a process can be traced by at most one other
process.  This prevents the formation of the sort of heavily redundant
mesh you seem to be thinking of.  I see another possibility here which
I think is serious enough that I won't mention it on a public mailing
list; I'm going to send it to security-officer instead, because I see
fairly nasty potential for abuse.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B