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]

Date:   Wed, 18 Mar 2020 13:21:44 +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 Wed, Mar 18, 2020 at 10:16:07AM +0000, Simon Ser wrote:
> 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.)

Yes, it would. My point was rather if pidfds mean something more than
identity at some point then we just need to make sure that you can only
get a getsockopt+pidfd_open(pid, 0) equivalent pidfd from it, i.e. one
without additional abilities (see below).

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

As a concrete example, think of it as root calling clone3() with e.g. an
additional flag PIDFD_GETFD which would stash the creds of the calling
process (in this example root) and when pidfd_getfd() is passed such a
pidfd it would use the creds of root instead of the calling threads
cred. This would e.g. allow a process to delegate the ability to
retrieve file descriptors from another task but nothing else.

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