linux-kernel - Re: siginfo pid not populated from ptrace?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181206192059.GD10086@cisco>
Date:   Thu, 6 Dec 2018 12:20:59 -0700
From:   Tycho Andersen <tycho@...ho.ws>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Kees Cook <keescook@...omium.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Oleg Nesterov <oleg@...hat.com>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: siginfo pid not populated from ptrace?

On Thu, Dec 06, 2018 at 10:48:39AM -0800, Linus Torvalds wrote:
> On Thu, Dec 6, 2018 at 6:40 AM Eric W. Biederman <ebiederm@...ssion.com> wrote:
> >
> > We have in the past had ptrace users that weren't just about debugging
> > so I don't know that it is fair to just dismiss it as debugging
> > infrastructure.
> 
> Absolutely.
> 
> Some uses are more than just debug. People occasionally use ptrace
> because it's the only way to do what they want, so you'll find people
> who do it for sandboxing, for example. It's not necessarily designed
> for that, or particularly fast or well-suited for it, but I've
> definitely seen it used that way.
> 
> So I don't think the behavioral test breakage like this is necessarily
> a huge deal, and until some "real use" actually shows that it cares it
> might be something we dismiss as "just test", but it very much has the
> potential to hit real uses.
> 
> The fact that a behavioral test broke is definitely interesting.
> 
> And maybe some of the siginfo allocations could depend on whether the
> signal is actually ever caught or not.
> 
> For example, a terminal signal (or one that is ignored) might not need
> siginfo. But if the process is ptraced, maybe that terminal signal
> isn't actually terminal? So we might have situations where we want to
> simply check "is the signal target being ptraced"..

Yes, something like this, I suppose? It works for me.

Tycho


>From 3bcaadd56ebb532ab4d481556fcc0826d65efc43 Mon Sep 17 00:00:00 2001
From: Tycho Andersen <tycho@...ho.ws>
Date: Thu, 6 Dec 2018 12:15:22 -0700
Subject: [PATCH] signal: allocate siginfo when a traced task gets SIGSTOP

Tracers can view SIGSTOP:

https://lore.kernel.org/lkml/87zhtthkuy.fsf@xmission.com/T/#u

so let's allocate a siginfo for SIGSTOP when a task is traced.

Signed-off-by: Tycho Andersen <tycho@...ho.ws>
---
 kernel/signal.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 9a32bc2088c9..ab4ba00119f4 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1056,11 +1056,14 @@ static int __send_signal(int sig, struct kernel_siginfo *info, struct task_struc
 		goto ret;
 
 	result = TRACE_SIGNAL_DELIVERED;
+
 	/*
-	 * Skip useless siginfo allocation for SIGKILL SIGSTOP,
-	 * and kernel threads.
+	 * Skip useless siginfo allocation for SIGKILL and kernel threads.
+	 * SIGSTOP is visible to tracers, so only skip allocation when the task
+	 * is not traced.
 	 */
-	if (sig_kernel_only(sig) || (t->flags & PF_KTHREAD))
+	if ((sig == SIGKILL) || (!task_is_traced(t) && sig == SIGSTOP) ||
+	    (t->flags & PF_KTHREAD))
 		goto out_set;
 
 	/*
-- 
2.19.1