All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Robert Święcki" <robert@swiecki.net>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"Will Drewry" <wad@chromium.org>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH 0/3] signal: HANDLER_EXIT should clear SIGNAL_UNKILLABLE
Date: Thu, 10 Feb 2022 10:41:57 -0800	[thread overview]
Message-ID: <202202101033.9C04563D9@keescook> (raw)
In-Reply-To: <871r0a8u29.fsf@email.froward.int.ebiederm.org>

On Thu, Feb 10, 2022 at 12:17:50PM -0600, Eric W. Biederman wrote:
> Kees Cook <keescook@chromium.org> writes:
> 
> > Hi,
> >
> > This fixes the signal refactoring to actually kill unkillable processes
> > when receiving a fatal SIGSYS from seccomp. Thanks to Robert for the
> > report and Eric for the fix! I've also tweaked seccomp internal a bit to
> > fail more safely. This was a partial seccomp bypass, in the sense that
> > SECCOMP_RET_KILL_* didn't kill the process, but it didn't bypass other
> > aspects of the filters. (i.e. the syscall was still blocked, etc.)
> 
> Any luck on figuring out how to suppress the extra event?

I haven't found a good single indicator of a process being in an "I am dying"
state, and even if I did, it seems every architecture's exit path would
need to add a new test.

The best approach seems to be clearing the TIF_*WORK* bits, but that's
still a bit arch-specific. And I'm not sure which layer would do that.
At what point have we decided the process will not continue? More
than seccomp was calling do_exit() in the middle of a syscall, but those
appear to have all been either SIGKILL or SIGSEGV?

-- 
Kees Cook

  reply	other threads:[~2022-02-10 18:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10  2:53 [PATCH 0/3] signal: HANDLER_EXIT should clear SIGNAL_UNKILLABLE Kees Cook
2022-02-10  2:53 ` [PATCH 1/3] " Kees Cook
2022-02-10 16:18   ` Jann Horn
2022-02-10 17:37     ` Kees Cook
2022-02-10 18:01       ` Jann Horn
2022-02-10 18:12         ` Eric W. Biederman
2022-02-10 21:09         ` Kees Cook
2022-02-11 20:15           ` Jann Horn
2022-02-10 18:16   ` Eric W. Biederman
2022-02-10  2:53 ` [PATCH 2/3] seccomp: Invalidate seccomp mode to catch death failures Kees Cook
2022-02-10  2:53 ` [PATCH 3/3] samples/seccomp: Adjust sample to also provide kill option Kees Cook
2022-02-10 18:17 ` [PATCH 0/3] signal: HANDLER_EXIT should clear SIGNAL_UNKILLABLE Eric W. Biederman
2022-02-10 18:41   ` Kees Cook [this message]
2022-02-10 18:58     ` Eric W. Biederman
2022-02-10 20:43       ` Kees Cook
2022-02-10 22:48         ` Eric W. Biederman
2022-02-11  1:26           ` Kees Cook
2022-02-11  1:47             ` Eric W. Biederman
2022-02-11  2:53               ` Kees Cook
2022-02-11 12:54                 ` Robert Święcki
2022-02-11 17:46                   ` Eric W. Biederman
2022-02-11 18:57                     ` Robert Święcki
2022-02-11 20:01                     ` Kees Cook
2022-02-11 19:58                   ` Kees Cook

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=202202101033.9C04563D9@keescook \
    --to=keescook@chromium.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=robert@swiecki.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.