linux-kernel - Re: SO_PEERCRED and pidfd

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]

Message-ID: <20200317181843.iq3jaboqid2xfktv@wittgenstein>
Date:   Tue, 17 Mar 2020 19:18:43 +0100
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     Simon Ser <contact@...rsion.fr>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "oleg@...hat.com" <oleg@...hat.com>,
        "christian@...uner.io" <christian@...uner.io>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>
Subject: Re: SO_PEERCRED and pidfd

On Tue, Mar 17, 2020 at 05:54:47PM +0000, Simon Ser wrote:
> 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