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

[Oleg Nesterov]

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.

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.

Oleg.

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