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:   Mon, 02 Oct 2017 22:25:32 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Jürg Billeter <j@...ron.ch>,
        Oleg Nesterov <oleg@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Filipe Brandenburger <filbranden@...gle.com>,
        David Wilcox <davidvsthegiant@...il.com>,
        "Adam H . Peterson" <alphaetapi@...mail.com>, hansecke@...il.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Andrew Morton <akpm@...ux-foundation.org> writes:

> On Fri, 29 Sep 2017 14:30:58 +0200 Jürg Billeter <j@...ron.ch> wrote:
>
>> PR_SET_PDEATHSIG sets a parent death signal that the calling process
>> will get when its parent thread dies, even when the result of getppid()
>> doesn't change because the calling process is reparented to a different
>> thread in the same parent process. When managing multiple processes, a
>> process-based parent death signal is much more useful. E.g., to avoid
>> stray child processes.
>> 
>> PR_SET_PDEATHSIG_PROC sets a process-based death signal. Unlike
>> PR_SET_PDEATHSIG, this is inherited across fork to allow killing a whole
>> subtree without race conditions.
>> 
>> This can be used for sandboxing when combined with a seccomp filter.
>> 
>> There have been previous attempts to support this by changing the
>> behavior of PR_SET_PDEATHSIG. However, that would break existing
>> applications. See https://marc.info/?l=linux-kernel&m=117621804801689
>> and https://bugzilla.kernel.org/show_bug.cgi?id=43300
>
> Are Eric and Oleg OK with this?
>
> A prctl manpage update will be needed, please (cc linux-api).

It makes for an interesting way of killing a process tree.  The domino
effect.

I believe the rational for adding a new prctl.

The code where it calls group_send_sig_info is buggy for pdeath_signal.
And it no less buggy for this new case.  There is no point to check
permissions when sending a signal to yourself.  Especially this signal
gets cleared during exec with a change of permissions.


I would recommend using:
 do_send_sig_info(p->signal->pdeath_signal_proc, SEND_SIG_NOINFO, p, true);

Perhaps with a comment saying that no permission check is needed when
sending a signal to yourself.


I don't know what I think about inherit over fork, and the whole tree
killing thing.  Except when the signal is SIGKILL I don't know if that
code does what is intended.  So I am a little leary of it.

Eric