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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Mar 2023 12:12:12 +0100
From:   Lennart Poettering <mzxreary@...inter.de>
To:     Christian Brauner <brauner@...nel.org>
Cc:     Eric Dumazet <edumazet@...gle.com>, 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
Subject: Re: [PATCH net-next 1/3] scm: add SO_PASSPIDFD and SCM_PIDFD

On Fr, 17.03.23 11:20, Christian Brauner (brauner@...nel.org) wrote:

> > > It seems that we already can use pidfd_open() (since linux-5.3), and
> > > pass the resulting fd in af_unix SCM_RIGHTS message ?

So yes, this is of course possible, but it would mean the pidfd would
have to be transported as part of the user protocol, explicitly sent
by the sender. (Moreover, the receiver after receiving the pidfd would
then still have to somehow be able to prove that the pidfd it just
received actually refers to the peer's process and not some random
process. – this part is actually solvable in userspace, but ugly)

The big thing is simply that we want that the pidfd is associated
*implicity* with each AF_UNIX connection, not explicitly. A lot of
userspace already relies on this, both in the authentication area
(polkit) as well as in the logging area (systemd-journald). Right now
using the PID field from SO_PEERCREDS/SCM_CREDENTIALS is racy though
and very hard to get right. Making this available as pidfd too, would
solve this raciness, without otherwise changing semantics of it all:
receivers can still enable the creds stuff as they wish, and the data
is then implicitly appended to the connections/datagrams the sender
initiates.

Or to turn this around: things like polkit are typically used to
authenticate arbitrary dbus methods calls: some service implements a
dbus method call, and when an unprivileged client then issues that
call, it will take the client's info, go to polkit and ask it if this
is ok. If we wanted to send the pidfd as part of the protocol we
basically would have to extend every single method call to contain the
client's pidfd along with it as an additional argument, which would be
a massive undertaking: it would change the prototypes of basically
*all* methods a service defines… And that's just ugly.

Note that Alex' patch set doesn't expose anything that wasn't exposed
before, or attach, propagate what wasn't before. All it does, is make
the field already available anyway (the struct ucred .pid field)
available also in a better way (as a pidfd), to solve a variety of
races, with no effect on the protocol actually spoken within the
AF_UNIX transport. It's a seamless improvement of the status quo.

Lennart

--
Lennart Poettering, Berlin