Skip to content
  • Tycho Andersen's avatar
    seccomp: add ptrace options for suspend/resume · 13c4a901
    Tycho Andersen authored
    
    
    This patch is the first step in enabling checkpoint/restore of processes
    with seccomp enabled.
    
    One of the things CRIU does while dumping tasks is inject code into them
    via ptrace to collect information that is only available to the process
    itself. However, if we are in a seccomp mode where these processes are
    prohibited from making these syscalls, then what CRIU does kills the task.
    
    This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
    a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
    filters to disable (and re-enable) seccomp filters for another task so that
    they can be successfully dumped (and restored). We restrict the set of
    processes that can disable seccomp through ptrace because although today
    ptrace can be used to bypass seccomp, there is some discussion of closing
    this loophole in the future and we would like this patch to not depend on
    that behavior and be future proofed for when it is removed.
    
    Note that seccomp can be suspended before any filters are actually
    installed; this behavior is useful on criu restore, so that we can suspend
    seccomp, restore the filters, unmap our restore code from the restored
    process' address space, and then resume the task by detaching and have the
    filters resumed as well.
    
    v2 changes:
    
    * require that the tracer have no seccomp filters installed
    * drop TIF_NOTSC manipulation from the patch
    * change from ptrace command to a ptrace option and use this ptrace option
      as the flag to check. This means that as soon as the tracer
      detaches/dies, seccomp is re-enabled and as a corrollary that one can not
      disable seccomp across PTRACE_ATTACHs.
    
    v3 changes:
    
    * get rid of various #ifdefs everywhere
    * report more sensible errors when PTRACE_O_SUSPEND_SECCOMP is incorrectly
      used
    
    v4 changes:
    
    * get rid of may_suspend_seccomp() in favor of a capable() check in ptrace
      directly
    
    v5 changes:
    
    * check that seccomp is not enabled (or suspended) on the tracer
    
    Signed-off-by: default avatarTycho Andersen <tycho.andersen@canonical.com>
    CC: Will Drewry <wad@chromium.org>
    CC: Roland McGrath <roland@hack.frob.com>
    CC: Pavel Emelyanov <xemul@parallels.com>
    CC: Serge E. Hallyn <serge.hallyn@ubuntu.com>
    Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
    Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
    [kees: access seccomp.mode through seccomp_mode() instead]
    Signed-off-by: default avatarKees Cook <keescook@chromium.org>
    13c4a901