linux-kernel - Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG

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: <87wp4c81wj.fsf@xmission.com>
Date:   Tue, 03 Oct 2017 14:30:36 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Jürg Billeter <j@...ron.ch>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Filipe Brandenburger <filbranden@...gle.com>,
        David Wilcox <davidvsthegiant@...il.com>, hansecke@...il.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Tue, Oct 3, 2017 at 9:36 AM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>
>> *Scratches head*
>> pdeath_signal is cleared during exec if bprm->cap_elevated.
>
> It's not cleared if we are *releasing* capabilities, which is exactly
> what might cause a "we can no longer send a signal"

*Doh*  Now I see where you are coming from.

>> is_setid is set if the uid != eid or gid != egid.
>
> Again, that may be exactly what changes - the original process may
> have uid != euid, and now we're going from an "we still had a root
> uid/suid" to "dropping everything to euid".
>
> IOW, we're _dropping_ capabilities, not adding them. Maybe we don't
> want to allow signaling the original parent any more.

We never signal the orignal parent.  We signal the child that
requested the pdeath_signal when the original parent dies.

The permission check is:
   Does the parent have permission to signal the child that requested
   the signal.

So the child dropping permissions won't change the result of that
permission check one iota.

The parent dropping permissions may change the result of that permission
check.

I care about this case because we already have the pdeath_signal and the
permission check doesn't make any sense to me, and appears not to be at all
useful.

Plus it is the only caller of group_send_sig_info outside of
kernel/signal.c so I think the kernel would be more maintainable if we
could simplify this piece of code.

> That said, as mentioned, I actually don't think it's a real problem.
> The real problem is entirely conceptual: yet more complexity in an
> area that we've already had problems in before.

>From the conversation so far it does appear we can do better.

Eric