linux-kernel - Re: [PATCH] ipc/mqueue.c: change __do_notify() to bypass check_kill

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, 23 Mar 2020 21:57:14 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Oleg Nesterov <oleg@...hat.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Manfred Spraul <manfred@...orfullife.com>,
        Markus Elfring <elfring@...rs.sourceforge.net>,
        Yoji <yoji.fujihar.min@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ipc/mqueue.c: change __do_notify() to bypass check_kill_permission()

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

> On Mon, 23 Mar 2020 11:47:12 -0500 ebiederm@...ssion.com (Eric W. Biederman) wrote:
>
>> I really just want to be certain that things are fixed well enough that
>> we don't risk a regressing again the next time someone touches the code.
>
> That would be nice ;)
>
> But as Oleg indicated, please let's have something minimal for -stable
> backporting friendliness.  A more comprehensive change can then be
> merged following the regular processes.

So far what we have is a report Oleg has read somewhere that some
program doing something regressed, and his patch to fix that specific
program.  This problem was not noticed for several years.

Presumably the problem is that a message queue was written to by one
user and was read by another user to cause check_kill_permission to
fail. Can someone tell me if that was the case?

At this point all we have are my vague hand wavy readings of the unix98
that even says not checking permissions is correct.

I could reheat the silly arguments I have seen around pdeath_signal and
why pdeath_signal needs a permission check to say that this mq_notify
also needs a permission check to prevent signaling a processes we should
not be able to signal.

So I am looking for something that makes it clear we are not removing
a permission checking and backporting a security hole.

Further even if in the common case it is the right thing to do to remove
the permission check, the handling around exec looks bad enough that we
will be backporting a security hole if we don't fix that and backport
that at the same time.

Eric

p.s. I am grouchy as temporary fixes in this part of the code base
     don't tend to be temporary  and the entire signal/exec/ptrace world
     is bordering on unmaintainble and incomprehensible as a result.