x86, seccomp: Run seccomp after ptrace hooks
The idea behind running seccomp before notifying ptrace about syscalls
was to reduce the attack surface. This never really worked: the
interesting attack surface in ptrace has nothing to do with the
registers at the time of a syscall, and, unless the seccomp policy
blocked *all* syscalls, all it could do was constrain the register
state.
This changes the logic so that ptrace runs before seccomp. This gives
ptrace a more sensible view of filtered processes, and it allows seccomp
to filter whatever ptrace changes a syscall to.
This is an ABI change. I don't expect it cause problems, because, in
older kernels, the registers seen by ptracers were already unpredictable.
In particular, orig_ax could have been -1 or the original syscall number
for skipped syscalls, depending on kernel version.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
2 files changed
