On Thu, Feb 5, 2015 at 3:39 PM, Dmitry V. Levin [off-list ref] wrote:

On Thu, Feb 05, 2015 at 03:12:39PM -0800, Kees Cook wrote:

quoted

On Thu, Feb 5, 2015 at 1:52 PM, Andy Lutomirski [off-list ref] wrote:

quoted

On Thu, Feb 5, 2015 at 1:40 PM, Dmitry V. Levin [off-list ref] wrote:

quoted

On Thu, Feb 05, 2015 at 01:27:16PM -0800, Kees Cook wrote:

quoted

On Thu, Feb 5, 2015 at 1:19 PM, Dmitry V. Levin [off-list ref] wrote:

quoted

Hi,

On Fri, Sep 05, 2014 at 03:13:54PM -0700, Andy Lutomirski wrote:

quoted

This splits syscall_trace_enter into syscall_trace_enter_phase1 and
syscall_trace_enter_phase2.  Only phase 2 has full pt_regs, and only
phase 2 is permitted to modify any of pt_regs except for orig_ax.

This breaks ptrace, see below.

[...]

quoted

quoted

quoted

quoted

quoted

quoted

+             ret = seccomp_phase1(&sd);
+             if (ret == SECCOMP_PHASE1_SKIP) {
+                     regs->orig_ax = -1;

How the tracer is expected to get the correct syscall number after that?

There shouldn't be a tracer if a skip is encountered. (A seccomp skip
would skip ptrace.) This behavior hasn't changed, but maybe I don't
see what you mean? (I haven't encountered any problems with syscall
tracing as a result of these changes.)

SECCOMP_RET_ERRNO leads to SECCOMP_PHASE1_SKIP, and if there is a tracer,
it will get -1 as a syscall number.

I've found this while testing a strace parser for
SECCOMP_MODE_FILTER/SECCOMP_SET_MODE_FILTER, so the problem is quite real.

Hasn't it always been this way?

As far as I know, yes, it's always been this way. The point is to the
skip the syscall, which is what the -1 signals. Userspace then reads
back the errno.

There is a clear difference: before these changes, SECCOMP_RET_ERRNO used
to keep the syscall number unchanged and suppress syscall-exit-stop event,
which was awful because userspace cannot distinguish syscall-enter-stop
from syscall-exit-stop and therefore relies on the kernel that
syscall-enter-stop is followed by syscall-exit-stop (or tracee's death, etc.).

After these changes, SECCOMP_RET_ERRNO no longer causes syscall-exit-stop
events to be suppressed, but now the syscall number is lost.

Ah-ha! Okay, thanks, I understand now. I think this means seccomp
phase1 should not treat RET_ERRNO as a "skip" event. Andy, what do you
think here?

-Kees

-- 
Kees Cook
Chrome OS Security