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]

Date:   Tue, 3 Oct 2017 10:02:53 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
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

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"

> 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.

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.

             Linus