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

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

Date:   Wed, 18 Mar 2020 10:16:07 +0000
From:   Simon Ser <contact@...rsion.fr>
To:     Christian Brauner <christian.brauner@...ntu.com>
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 Tuesday, March 17, 2020 7:18 PM, Christian Brauner <christian.brauner@...ntu.com> wrote:

> 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.

Wouldn't this new mechanism just be an atomic getsockopt+pidfd_open?
(It would make sure the process is still alive of course.)

Can you elaborate wrt. capabilities? I'm not sure I understand what
that means.

> 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.)

Yeah, this would need to be either a separate SO_* flag or a completely
different thing to prevent surprises.