Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1407782

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

Show all headers | View raw

On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> 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.)

I'm really against this. I think seccomp needs to stay first, and I
like the two-phase split because it gives us a lot of flexibility on
other architectures. And we can't just let through RET_TRACE because
we'll have exactly the same problem: a process can add a RET_TRACE
filter for some syscall and then change it arbitrarily to escape the
filtering. The non-trace returns of seccomp need to be check first and
after ptrace manipulations. The patch seems like the best approach and
it covers all the corners.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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