SO_PEERCRED and pidfd

[Simon Ser]

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?

Thanks,

Simon Ser

[1]: https://gitlab.freedesktop.org/wayland/weston/issues/206
[2]: https://github.com/flatpak/flatpak/issues/2995

[Christian Brauner]

Post by Simon Ser
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?

Puh, I knew this would happen. I've been asked to add this feature by
the systemd people as well and also at a conference last year. And
honestly, I don't know yet. pidfds right now are mostly about
guaranteeing (stable) identity and they come with the necessary
restrictions in place to prevent shenanigans (such as signaling across
pid namespaces a restriction I'd like to lift at _some_ point). But I
have been thinking about attaching some capability like features to
pidfds soon as that has been an even more frequent request. At that
point having them receivable this way might be problematic unless we put
restrictions in place.

I would like to go through codepaths for SO_PEERCRED as I don't have
them in my head and so can't really say something definitely about this
just now.
(From the top of my head it seems that if we were to do this it might
need to be a separate SO_* flag? Mainly so people don't suddenly receive
fds they didn't expect.)

Christian

[Eric W. Biederman]

Post by Simon Ser
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

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