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