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] [day] [month] [year] [list]

Message-ID: <87tvjl1dxg.fsf@xmission.com>
Date:   Mon, 10 Dec 2018 11:36:59 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     Tycho Andersen <tycho@...ho.ws>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: siginfo pid not populated from ptrace?

Oleg Nesterov <oleg@...hat.com> writes:

> On 12/06, Eric W. Biederman wrote:
>>
>> The challenge is that we could be delivering this to a zombie signal
>> group leader.
>
> ...
>
>> Sigh it is probably time that I dig in and figure out how to avoid that
>> case which we need to fix anyway because we can get the permission
>> checks wrong for multi-threaded processes that call setuid and friends.
>
> this is another issue... I am sure we have already discussed this, but I
> failed to find any link to the previous discussion.

Now that we have PIDTYPE_TGID I think we are closer to being able to
solve that issue.  You are absolutely right it is another issue.

>> Once that is sorted your small change will at least be safe.
>
> I don't think so, any sub-thread can dequeue SIGSTOP unless type == PIDTYPE_PID,
> this has nothing to do with the problems connected to zombie leader, or I
> misunderstood you.

I forgot to check what wants_signal does in this case.  I thought
SIGSTOP was like SIGKILL and being unblockable would always be delivered
to the thread we are aiming at.  With a zombie leader being the
exception.

Having reread wants_signal you are absolutely correct.  SIGSTOP can be
delivered to any thread so this won't help.  I don't understand why for
SIGSTOP we don't treat SIGSTOP like SIGKILL, but that is also another
conversation.  It feels like the differences between SIGSTOP and SIGKILL
in wants_signal are silly.  I don't see them leading to incorrect behavior.

Eric