On Wed, January 18, 2012 18:00, Oleg Nesterov wrote: > On 01/17, Chris Evans wrote: >> >> 1) Tracee is compromised; executes fork() which is syscall that isn't allowed >> 2) Tracee traps >> 2b) Tracee could take a SIGKILL here >> 3) Tracer looks at registers; bad syscall >> 3b) Or tracee could take a SIGKILL here >> 4) The only way to stop the bad syscall from executing is to rewrite >> orig_eax (PTRACE_CONT + SIGKILL only kills the process after the >> syscall has finished) >> 5) Disaster: the tracee took a SIGKILL so any attempt to address it by >> pid (such as PTRACE_SETREGS) fails. >> 6) Syscall fork() executes; possible unsupervised process now running >> since the tracer wasn't expecting the fork() to be allowed. > > As for fork() in particular, it can't succeed after SIGKILL. That was sadly exactly the system call I used for testing my code... > But I agree, probably it makes sense to change ptrace_stop() to check > fatal_signal_pending() and do do_group_exit(SIGKILL) after it sleeps > in TASK_TRACED. Or we can change tracehook_report_syscall_entry() > > - return 0; > + return !fatal_signal_pending(); > > (no, I do not literally mean the change above) > > Not only for security. The current behaviour sometime confuses the > users. Debugger sends SIGKILL to the tracee and assumes it should > die asap, but the tracee exits only after syscall. I didn't expect the tracer to die asap when sending SIGKILL, but I did for PTRACE_KILL. Improving this behaviour is highly appreciated, thanks! Greetings, Indan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
