Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   ebiederm@xmission.com (Eric W. Biederman)
To:     Simon Ser <contact@emersion.fr>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "oleg\@redhat.com" <oleg@redhat.com>,
        "christian\@brauner.io" <christian@brauner.io>
References: <go0RLOS7_DdxyAmfrDR38QPUloZuUtiFdXe2Ey3EkGGuvmW7z18Dvt4fY1qZ1k-Y75-YZSxqVWnZpWRGN7TZ6OPbDczfL7HI25bXLIYq1y4=@emersion.fr>
Date:   Tue, 17 Mar 2020 13:58:46 -0500
In-Reply-To: <go0RLOS7_DdxyAmfrDR38QPUloZuUtiFdXe2Ey3EkGGuvmW7z18Dvt4fY1qZ1k-Y75-YZSxqVWnZpWRGN7TZ6OPbDczfL7HI25bXLIYq1y4=@emersion.fr>
        (Simon Ser's message of "Tue, 17 Mar 2020 17:54:47 +0000")
Message-ID: <87d09akduh.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: SO_PEERCRED and pidfd
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Simon Ser <contact@emersion.fr> writes:

> Hi all,
>
> I'm a Wayland developer and I've been working on protocol security,
> which involves identifying the process on the other end of a Unix
> socket [1]. This is already done by e.g. D-Bus via the PID, however
> this is racy [2].
>
> Getting the PID is done via SO_PEERCRED. Would there be interest in
> adding a way to get a pidfd out of a Unix socket to fix the race?

I think we are passing a struct pid through the socket metadata.
So it should be technically feasible.

However it does come with some long term mainteance costs.

The big question is what is a pid being used for when being passed.
Last I looked most of the justifications for using metadata like that
with unix domain sockets led to patterns of trust that were also
exploitable.

Looking at the proposale in [1] even if you have race free access
to /proc/<pid>/exe using pidfds it is possible to change /proc/<pid>/exe
to be anything you can map so that seems to be an example of a problem.

So it would be very nice to see a use case spelled out where
the pid reuse race mattered, and that trusting a pid makes sense.


I have to dash but I will think about this and see if I can give a
concrete example of using a capability model.  Other than the current
one that works (handing out trusted sockets at the logical beginning of
time).  Though frankly I am not certain there is anything much better
than that.

Eric


> Thanks,
>
> Simon Ser
>
> [1]: https://gitlab.freedesktop.org/wayland/weston/issues/206
> [2]: https://github.com/flatpak/flatpak/issues/2995