linux-kernel - Re: SO_PEERCRED and 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: <87d09akduh.fsf@x220.int.ebiederm.org>
Date:   Tue, 17 Mar 2020 13:58:46 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Simon Ser <contact@...rsion.fr>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "oleg\@redhat.com" <oleg@...hat.com>,
        "christian\@brauner.io" <christian@...uner.io>
Subject: Re: SO_PEERCRED and pidfd

Simon Ser <contact@...rsion.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