From: ebiederm@xmission.com (Eric W. Biederman)
To: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
Will Drewry <wad@chromium.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH 0/2] selftests/seccomp: Report event mismatches more clearly
Date: Wed, 03 Nov 2021 14:17:56 -0500 [thread overview]
Message-ID: <871r3xyrob.fsf@disp2133> (raw)
In-Reply-To: <202111031139.80CE97C532@keescook> (Kees Cook's message of "Wed, 3 Nov 2021 11:40:23 -0700")
Kees Cook <keescook@chromium.org> writes:
> On Wed, Nov 03, 2021 at 01:37:51PM -0500, Eric W. Biederman wrote:
>> Kees Cook <keescook@chromium.org> writes:
>>
>> > Hi,
>> >
>> > This expands the seccomp selftests slightly to add additional debug
>> > reporting detail and a new "immediate fatal SIGSYS under tracing" test.
>> > I expect to be taking these via my seccomp tree.
>>
>> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>
>> I am a little fuzzy on the details but I understand what and why
>> you are testing (I broken it). So this is my 10,000 foot ack.
>
> Thanks! Yeah, and the other tests did catch it, but it was kind of a
> "side effect", so I added the specific "direct" case where it can be
> seen more clearly.
Hey. Did you happen to understand the bit about racing with sigaction?
As much as I care about not braking ptrace. What really decided me was
the on SA_IMMUTABLE was closing the race with sigaction changing the
signal handler. Especially for something like seccomp.
It is a race so probably very fickle to write a test for, but if we can
figure out how to write a reliable test I expect it will be a good idea.
Do you have any ideas?
I am concerned there is some threaded program somewhere using seccomp
that is allowed to call sigaction, can use sigaction to keep from
being killed (before I send the fix to Linus).
Eric
prev parent reply other threads:[~2021-11-03 19:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-03 16:30 [PATCH 0/2] selftests/seccomp: Report event mismatches more clearly Kees Cook
2021-11-03 16:30 ` [PATCH 1/2] selftests/seccomp: Stop USER_NOTIF test if kcmp() fails Kees Cook
2021-11-03 16:30 ` [PATCH 2/2] selftests/seccomp: Report event mismatches more clearly Kees Cook
2021-11-03 18:37 ` [PATCH 0/2] " Eric W. Biederman
2021-11-03 18:40 ` Kees Cook
2021-11-03 19:17 ` 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=871r3xyrob.fsf@disp2133 \
--to=ebiederm@xmission.com \
--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=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.