lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 01 Nov 2021 17:28:07 -0500
From: (Eric W. Biederman)
To:     Andrea Righi <>
Cc:     Kees Cook <>, Shuah Khan <>,
        Alexei Starovoitov <>,
        Andy Lutomirski <>,
        Will Drewry <>,,,,
Subject: Re: [PATCH] signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed

Andrea Righi <> writes:

> On Fri, Oct 29, 2021 at 10:09:04AM -0500, Eric W. Biederman wrote:
>> 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]
>> [2]
>> Cc:
>> Fixes: 307d522f5eb8 ("signal/seccomp: Refactor seccomp signal and coredump generation")
>> Signed-off-by: "Eric W. Biederman" <>
>> ---
> FWIW I've tested this patch and I confirm that it fixes the failure that
> I reported with the seccomp_bpf selftest.
> Tested-by: Andrea Righi <>

Sigh.  Except for the extra 0 in the definition of SA_IMMUTABLE
that caused it to conflict with the x86 specific signal numbers.


Powered by blists - more mailing lists