On Thu, Mar 16, 2023 at 04:32:03PM +0100, Aleksandr Mikhalitsyn wrote: > On Thu, Mar 16, 2023 at 3:34 PM Eric Dumazet <edumazet@xxxxxxxxxx> wrote: > > > > On Thu, Mar 16, 2023 at 6:16 AM Alexander Mikhalitsyn > > <aleksandr.mikhalitsyn@xxxxxxxxxxxxx> wrote: > > > > > > Implement SCM_PIDFD, a new type of CMSG type analogical to SCM_CREDENTIALS, > > > but it contains pidfd instead of plain pid, which allows programmers not > > > to care about PID reuse problem. > > > > Hi Alexander > > Hi Eric > > Thanks for the fast reply! ;-) > > > > > This would add yet another conditional in af_unix fast path. > > > > It seems that we already can use pidfd_open() (since linux-5.3), and > > pass the resulting fd in af_unix SCM_RIGHTS message ? > > Yes, it's possible, but it means that from the receiver side we need > to trust the sent pidfd (in SCM_RIGHTS), > or always use combination of SCM_RIGHTS+SCM_CREDENTIALS, then we can > extract pidfd from SCM_RIGHTS, > then acquire plain pid from pidfd and after compare it with the pid > from SCM_CREDENTIALS. > > > > > If you think this is not suitable, it should at least be mentioned in > > the changelog. Let me try and provide some of the missing background. There are a range of use-cases where we would like to authenticate a client through sockets without being susceptible to PID recycling attacks. Currently, we can't do this as the race isn't fully fixable. We can only apply mitigations. What this patchset will allows us to do is to get a pidfd without the client having to send us an fd explicitly via SCM_RIGHTS. As that's already possibly as you correctly point out. But for protocols like polkit this is quite important. Every message is standalone and we would need to force a complete protocol change where we would need to require that every client allocate and send a pidfd via SCM_RIGHTS. That would also mean patching through all polkit users. For something like systemd-journald where we provide logging facilities and want to add metadata to the log we would also immensely benefit from being able to get a receiver-side controlled pidfd. With the message type we envisioned we don't need to change the sender at all and can be safe against pid recycling. Link: https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/154 Link: https://uapi-group.org/kernel-features
