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: <CAKOZuettqvG0S=3XBjnBLZvMEQMPcQswwPXogSfxwJZA85fdBA@mail.gmail.com>
Date:   Mon, 1 Apr 2019 15:34:05 -0700
From:   Daniel Colascione <dancol@...gle.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Jonathan Kowalski <bl0pbl33p@...il.com>,
        Christian Brauner <christian@...uner.io>,
        Jann Horn <jannh@...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 3:13 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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.

Yes. Returning a pidfd from clone seems like a simple and robust approach.

> 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 doesn't work when some other thread is running a waitpid(-1)
loop. I think it's important to create an interface that libraries can
use without global coordination.

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

I don't like ignoring races just because they're rare. The cost of
complete race freedom for the process interface is low considering the
work we're doing on pidfds anyway.