From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrea Righi <andrea.righi@canonical.com>
Cc: Kees Cook <keescook@chromium.org>, Shuah Khan <shuah@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Will Drewry <wad@chromium.org>,
linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed
Date: Mon, 01 Nov 2021 17:28:07 -0500 [thread overview]
Message-ID: <87tugva4ug.fsf@disp2133> (raw)
In-Reply-To: <YX7VA1JZaYkTQeSi@arighi-desktop> (Andrea Righi's message of "Sun, 31 Oct 2021 18:40:19 +0100")
Andrea Righi <andrea.righi@canonical.com> 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] 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")
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>> ---
>
> 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 <andrea.righi@canonical.com>
Sigh. Except for the extra 0 in the definition of SA_IMMUTABLE
that caused it to conflict with the x86 specific signal numbers.
Eric
prev parent reply other threads:[~2021-11-01 22:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-28 16:21 selftests: seccomp_bpf failure on 5.15 Andrea Righi
2021-10-28 16:56 ` Kees Cook
2021-10-28 17:26 ` Eric W. Biederman
2021-10-28 18:47 ` Kees Cook
2021-10-28 22:06 ` Eric W. Biederman
2021-10-29 14:58 ` Kees Cook
2021-10-29 15:17 ` Eric W. Biederman
2021-11-02 18:22 ` Eric W. Biederman
2021-11-03 16:14 ` Kees Cook
2021-11-03 18:35 ` Eric W. Biederman
2021-10-29 15:09 ` [PATCH] signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed Eric W. Biederman
2021-10-31 17:40 ` Andrea Righi
2021-11-01 22:28 ` Eric W. Biederman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tugva4ug.fsf@disp2133 \
--to=ebiederm@xmission.com \
--cc=andrea.righi@canonical.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=shuah@kernel.org \
--cc=wad@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.