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]

Date:   Thu, 6 Dec 2018 10:48:39 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Kees Cook <keescook@...omium.org>, Tycho Andersen <tycho@...ho.ws>,
        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 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"..

              Linus