Kees Cook <keescook@xxxxxxxxxxxx> writes: > On Wed, Nov 03, 2021 at 01:37:51PM -0500, Eric W. Biederman wrote: >> Kees Cook <keescook@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> >> >> 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
