Messages in this thread | | | From | (Eric W. Biederman) | Date | Tue, 17 Mar 2020 13:58:46 -0500 | Subject | Re: SO_PEERCRED and pidfd |
| |
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
| |