• Kees Cook's avatar
    seccomp: Implement SECCOMP_RET_KILL_PROCESS action · 0466bdb9
    Kees Cook authored
    Right now, SECCOMP_RET_KILL_THREAD (neé SECCOMP_RET_KILL) kills the
    current thread. There have been a few requests for this to kill the entire
    process (the thread group). This cannot be just changed (discovered when
    adding coredump support since coredumping kills the entire process)
    because there are userspace programs depending on the thread-kill
    Instead, implement SECCOMP_RET_KILL_PROCESS, which is 0x80000000, and can
    be processed as "-1" by the kernel, below the existing RET_KILL that is
    ABI-set to "0". For userspace, SECCOMP_RET_ACTION_FULL is added to expand
    the mask to the signed bit. Old userspace using the SECCOMP_RET_ACTION
    mask will see SECCOMP_RET_KILL_PROCESS as 0 still, but this would only
    be visible when examining the siginfo in a core dump from a RET_KILL_*,
    where it will think it was thread-killed instead of process-killed.
    Attempts to introduce this behavior via other ways (filter flags,
    seccomp struct flags, masked RET_DATA bits) all come with weird
    side-effects and baggage. This change preserves the central behavioral
    expectations of the seccomp filter engine without putting too great
    a burden on changes needed in userspace to use the new action.
    The new action is discoverable by userspace through either the new
    actions_avail sysctl or through the SECCOMP_GET_ACTION_AVAIL seccomp
    operation. If used without checking for availability, old kernels
    will treat RET_KILL_PROCESS as RET_KILL_THREAD (since the old mask
    will produce RET_KILL_THREAD).
    Cc: Paul Moore <paul@paul-moore.com>
    Cc: Fabricio Voznika <fvoznika@google.com>
    Signed-off-by: default avatarKees Cook <keescook@chromium.org>
Last commit
Last update
conf.py Loading commit data...
index.rst Loading commit data...
no_new_privs.rst Loading commit data...
seccomp_filter.rst Loading commit data...
unshare.rst Loading commit data...