netdev - Re: [PATCH net-next 1/3] scm: add SO_PASSPIDFD and SCM

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]

Date:   Fri, 17 Mar 2023 11:20:11 +0100
From:   Christian Brauner <brauner@...nel.org>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     davem@...emloft.net,
        Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Leon Romanovsky <leon@...nel.org>,
        David Ahern <dsahern@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Kees Cook <keescook@...omium.org>, linux-arch@...r.kernel.org,
        Lennart Poettering <lennart@...ttering.net>
Subject: Re: [PATCH net-next 1/3] scm: add SO_PASSPIDFD and SCM_PIDFD

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@...gle.com> wrote:
> >
> > On Thu, Mar 16, 2023 at 6:16 AM Alexander Mikhalitsyn
> > <aleksandr.mikhalitsyn@...onical.com> 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