Re: Compat 32-bit syscall entry from 64-bit task!? [was: Re:[RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF]

[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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/