Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

From	Andy Lutomirski <luto@amacapital.net>
Newsgroups	linux.kernel
Subject	Re: [PATCH] seccomp: plug syscall-dodging ptrace hole
Date	2016-05-27 04:20 +0200
Message-ID	<rDfxv-5W2-5@gated-at.bofh.it> (permalink)
References	<rDaHw-2Xq-5@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Thu, May 26, 2016 at 2:04 PM, Kees Cook <keescook@chromium.org> wrote:
> One problem with seccomp was that ptrace could be used to change a
> syscall after seccomp filtering had completed. This was a well documented
> limitation, and it was recommended to block ptrace when defining a filter
> to avoid this problem. This can be quite a limitation for containers or
> other places where ptrace is desired even under seccomp filters.
>
> Since seccomp filtering has been split into pre-trace and trace phases
> (phase1 and phase2 respectively), it's possible to re-run phase1 seccomp
> after ptrace. This makes that change, and updates the test suite for
> both SECCOMP_RET_TRACE and PTRACE_SYSCALL manipulation.

I like fixing the hole, but I don't like this fix.

The two-phase seccomp mechanism is messy.  I wrote it because it was a
huge speedup.  Since then, I've made a ton of changes to the way that
x86 syscalls work, and there are two relevant effects: the slow path
is quite fast, and the phase-1-only path isn't really a win any more.

I suggest that we fix the by simplifying the code instead of making it
even more complicated.  Let's back out the two-phase mechanism (but
keep the ability for arch code to supply seccomp_data) and then just
reorder it so that seccomp happens after ptrace.  The result should be
considerably simpler.  (We'll still have to answer the question of
what happens when a SECCOMP_RET_TRACE event changes the syscall, but
maybe the answer is to just let it through -- after all,
SECCOMP_RET_TRACE might be a request by a tracer to do its own
internal filtering.)

--Andy

Thread

[PATCH] seccomp: plug syscall-dodging ptrace hole Kees Cook <keescook@chromium.org> - 2016-05-26 23:10 +0200
  Re: [PATCH] seccomp: plug syscall-dodging ptrace hole Jann Horn <jann@thejh.net> - 2016-05-27 01:00 +0200
  Re: [PATCH] seccomp: plug syscall-dodging ptrace hole Andy Lutomirski <luto@amacapital.net> - 2016-05-27 04:20 +0200
    Re: [PATCH] seccomp: plug syscall-dodging ptrace hole Kees Cook <keescook@chromium.org> - 2016-05-27 04:50 +0200
      Re: [PATCH] seccomp: plug syscall-dodging ptrace hole Andy Lutomirski <luto@amacapital.net> - 2016-05-27 06:50 +0200
        Re: [PATCH] seccomp: plug syscall-dodging ptrace hole Kees Cook <keescook@chromium.org> - 2016-05-27 20:50 +0200
          Re: [PATCH] seccomp: plug syscall-dodging ptrace hole Andy Lutomirski <luto@amacapital.net> - 2016-05-27 22:00 +0200
            Re: [PATCH] seccomp: plug syscall-dodging ptrace hole Andy Lutomirski <luto@amacapital.net> - 2016-05-27 22:20 +0200
            Re: [PATCH] seccomp: plug syscall-dodging ptrace hole Kees Cook <keescook@chromium.org> - 2016-05-28 00:40 +0200
              Re: [PATCH] seccomp: plug syscall-dodging ptrace hole Andy Lutomirski <luto@amacapital.net> - 2016-05-28 01:30 +0200
                Re: [PATCH] seccomp: plug syscall-dodging ptrace hole Kees Cook <keescook@chromium.org> - 2016-05-28 04:40 +0200

csiph-web