signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed
authorEric W. Biederman <ebiederm@xmission.com>
Fri, 29 Oct 2021 14:14:19 +0000 (09:14 -0500)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 18 Nov 2021 18:16:01 +0000 (19:16 +0100)
commit82d43437f88ca8e977dcfbcc5d4774948d1f936a
tree07930e6ab84d13acbb81a767438a1c91d1d92354
parente87f4856a2c4d0dfabe714ad6693e1224d04a99f
signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed

commit 00b06da29cf9dc633cdba87acd3f57f4df3fd5c7 upstream.

As Andy pointed out that there are races between
force_sig_info_to_task and sigaction[1] when force_sig_info_task.  As
Kees discovered[2] ptrace is also able to change these signals.

In the case of seeccomp killing a process with a signal it is a
security violation to allow the signal to be caught or manipulated.

Solve this problem by introducing a new flag SA_IMMUTABLE that
prevents sigaction and ptrace from modifying these forced signals.
This flag is carefully made kernel internal so that no new ABI is
introduced.

Longer term I think this can be solved by guaranteeing short circuit
delivery of signals in this case.  Unfortunately reliable and
guaranteed short circuit delivery of these signals is still a ways off
from being implemented, tested, and merged.  So I have implemented a much
simpler alternative for now.

[1] https://lkml.kernel.org/r/b5d52d25-7bde-4030-a7b1-7c6f8ab90660@www.fastmail.com
[2] https://lkml.kernel.org/r/202110281136.5CE65399A7@keescook
Cc: stable@vger.kernel.org
Fixes: 307d522f5eb8 ("signal/seccomp: Refactor seccomp signal and coredump generation")
Tested-by: Andrea Righi <andrea.righi@canonical.com>
Tested-by: Kees Cook <keescook@chromium.org>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
include/linux/signal_types.h
include/uapi/asm-generic/signal-defs.h
kernel/signal.c