All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Tso" <tytso@mit.edu>
Cc: Jann Horn <jannh@google.com>,
	Christian Brauner <brauner@kernel.org>,
	Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH RFC v3 2/4] pidfd: add CLONE_PIDFD_AUTOKILL
Date: Wed, 18 Feb 2026 08:29:54 -0500	[thread overview]
Message-ID: <20260218132954.GA45984@macsyma-wired.lan> (raw)
In-Reply-To: <CAHk-=wiPJfnTVq6vUF8K8kF0FfrY2svAqSwsL8xLEV76pVyEkg@mail.gmail.com>

On Tue, Feb 17, 2026 at 03:44:52PM -0800, Linus Torvalds wrote:
> On Tue, 17 Feb 2026 at 15:38, Jann Horn <jannh@google.com> wrote:
> >
> > You can already send SIGHUP to such binaries through things like job
> > control, right?
> 
> But at least those can be blocked, and people can disassociate
> themselves from a tty if they care etc.

Does CLONE_PIDFD_AUTOKILL need to send a SIGKILL?  Could it be
something that could be trapped/blocked, like SIGHUP or SIGTERM?  Or
maybe we could do the SIGHUP, wait 30 seconds (+/- a random delay), if
it hasn't exited, send SIGTERM, wait another 30 seconds (+/- a random
delay) if it hasn't exited send a SIGKILL.  That's still a change in
the security model, but it's less likely to cause problems if the goal
is to try to catch a setuid program while it is in the middle of
editing some critical file such as /etc/sudo.conf or /etc/passwd or
some such.

I bet we'll still see some zero days coming out of this, but we can at
least mitigate likelihood of security breach.

							- Ted
							

  parent reply	other threads:[~2026-02-18 13:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-17 22:35 [PATCH RFC v3 0/4] pidfd: add CLONE_AUTOREAP and CLONE_PIDFD_AUTOKILL Christian Brauner
2026-02-17 22:35 ` [PATCH RFC v3 1/4] clone: add CLONE_AUTOREAP Christian Brauner
2026-02-18 11:25   ` Oleg Nesterov
2026-02-18 13:30     ` Christian Brauner
2026-02-17 22:35 ` [PATCH RFC v3 2/4] pidfd: add CLONE_PIDFD_AUTOKILL Christian Brauner
2026-02-17 23:17   ` Linus Torvalds
2026-02-17 23:38     ` Jann Horn
2026-02-17 23:44       ` Linus Torvalds
2026-02-18  8:18         ` Christian Brauner
2026-02-18 14:00           ` Theodore Tso
2026-02-18 13:29         ` Theodore Tso [this message]
2026-02-18 10:21       ` Christian Brauner
2026-02-17 23:43   ` Jann Horn
2026-02-18 10:00     ` Christian Brauner
2026-02-18 11:50   ` Oleg Nesterov
2026-02-18 13:31     ` Christian Brauner
2026-02-17 22:35 ` [PATCH RFC v3 3/4] selftests/pidfd: add CLONE_AUTOREAP tests Christian Brauner
2026-02-17 22:35 ` [PATCH RFC v3 4/4] selftests/pidfd: add CLONE_PIDFD_AUTOKILL tests Christian Brauner
2026-02-17 22:46 ` [PATCH RFC v3 0/4] pidfd: add CLONE_AUTOREAP and CLONE_PIDFD_AUTOKILL Christian Brauner

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=20260218132954.GA45984@macsyma-wired.lan \
    --to=tytso@mit.edu \
    --cc=brauner@kernel.org \
    --cc=jannh@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.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.