Messages in this thread | | | Date | Thu, 19 Jan 2012 01:29:04 +0100 | Subject | Re: Compat 32-bit syscall entry from 64-bit task!? [was: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF] | From | "Indan Zupancic" <> |
| |
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
| |