Skip to content
  • Tycho Andersen's avatar
    seccomp: add a return code to trap to userspace · 6a21cc50
    Tycho Andersen authored
    
    
    This patch introduces a means for syscalls matched in seccomp to notify
    some other task that a particular filter has been triggered.
    
    The motivation for this is primarily for use with containers. For example,
    if a container does an init_module(), we obviously don't want to load this
    untrusted code, which may be compiled for the wrong version of the kernel
    anyway. Instead, we could parse the module image, figure out which module
    the container is trying to load and load it on the host.
    
    As another example, containers cannot mount() in general since various
    filesystems assume a trusted image. However, if an orchestrator knows that
    e.g. a particular block device has not been exposed to a container for
    writing, it want to allow the container to mount that block device (that
    is, handle the mount for it).
    
    This patch adds functionality that is already possible via at least two
    other means that I know about, both of which involve ptrace(): first, one
    could ptrace attach, and then iterate through syscalls via PTRACE_SYSCALL.
    Unfortunately this is slow, so a faster version would be to install a
    filter that does SECCOMP_RET_TRACE, which triggers a PTRACE_EVENT_SECCOMP.
    Since ptrace allows only one tracer, if the container runtime is that
    tracer, users inside the container (or outside) trying to debug it will not
    be able to use ptrace, which is annoying. It also means that older
    distributions based on Upstart cannot boot inside containers using ptrace,
    since upstart itself uses ptrace to monitor services while starting.
    
    The actual implementation of this is fairly small, although getting the
    synchronization right was/is slightly complex.
    
    Finally, it's worth noting that the classic seccomp TOCTOU of reading
    memory data from the task still applies here, but can be avoided with
    careful design of the userspace handler: if the userspace handler reads all
    of the task memory that is necessary before applying its security policy,
    the tracee's subsequent memory edits will not be read by the tracer.
    
    Signed-off-by: default avatarTycho Andersen <tycho@tycho.ws>
    CC: Kees Cook <keescook@chromium.org>
    CC: Andy Lutomirski <luto@amacapital.net>
    CC: Oleg Nesterov <oleg@redhat.com>
    CC: Eric W. Biederman <ebiederm@xmission.com>
    CC: "Serge E. Hallyn" <serge@hallyn.com>
    Acked-by: default avatarSerge Hallyn <serge@hallyn.com>
    CC: Christian Brauner <christian@brauner.io>
    CC: Tyler Hicks <tyhicks@canonical.com>
    CC: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
    Signed-off-by: default avatarKees Cook <keescook@chromium.org>
    6a21cc50