linux-kernel - Re: [PATCH v2 0/5] pid: add pidfd

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: <CAHk-=wiDjdoS4erUTjWaHMY+ZT28omwA24pPMRoQEE-rtNcRpw@mail.gmail.com>
Date:   Mon, 1 Apr 2019 15:13:23 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jonathan Kowalski <bl0pbl33p@...il.com>
Cc:     Christian Brauner <christian@...uner.io>,
        Jann Horn <jannh@...gle.com>,
        Daniel Colascione <dancol@...gle.com>,
        Aleksa Sarai <cyphar@...har.com>,
        Andy Lutomirski <luto@...capital.net>,
        Andrew Lutomirski <luto@...nel.org>,
        David Howells <dhowells@...hat.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Linux API <linux-api@...r.kernel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        Kees Cook <keescook@...omium.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Michael Kerrisk-manpages <mtk.manpages@...il.com>,
        "Dmitry V. Levin" <ldv@...linux.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Nagarathnam Muthusamy <nagarathnam.muthusamy@...cle.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Joel Fernandes <joel@...lfernandes.org>
Subject: Re: [PATCH v2 0/5] pid: add pidfd_open()

On Mon, Apr 1, 2019 at 2:58 PM Jonathan Kowalski <bl0pbl33p@...il.com> wrote:
>
> You mention the race about learning the PID, PID being recycled, and
> pidfd_open getting the wrong reference.
>
> This exists with the /proc model to way. How do you propose to address this?

Note that that race exists _regardless_ of any interfaces.
pidfd_open() has the same race: any time you have a pid, the lifetime
of it is only as long as the process existing.

That's why we talked about the CLONE_PIDFD flag, which would return
the pidfd itself when creating a new process. That's one truly
race-free way to handle it.

Or just do the fork(), and know that the pid won't be re-used until
you've done the wait() for it, and block SIGCHLD until you've done the
lookup.

That said, in *practice*, you can probably use any of the racy "look
up pidfd using pid" models, as long as you just verify the end result
after you've opened it.

That verification could be as simple as "look up the parent pid of the
pidfd I got", if you know you created it with fork() (and you can
obviously track what _other_ thread you yourself created, so you can
verify whether it is yours or not).

For example, using "openat(pidfd, "status", ..)", but also by just
tracking what you've done waitpid() on (but you need to look out for
subtle races with another thread being in the process of doing so).

Or you can just say that as long as you got the pidfd quickly after
the fork(), any pid wrapping attack is practically not possible even
if it might be racy in theory.

                         Linus