From: ebiederm@xmission.com (Eric W. Biederman)
To: Simon Ser <contact@emersion.fr>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"oleg\@redhat.com" <oleg@redhat.com>,
"christian\@brauner.io" <christian@brauner.io>
Subject: Re: SO_PEERCRED and pidfd
Date: Tue, 17 Mar 2020 13:58:46 -0500 [thread overview]
Message-ID: <87d09akduh.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <go0RLOS7_DdxyAmfrDR38QPUloZuUtiFdXe2Ey3EkGGuvmW7z18Dvt4fY1qZ1k-Y75-YZSxqVWnZpWRGN7TZ6OPbDczfL7HI25bXLIYq1y4=@emersion.fr> (Simon Ser's message of "Tue, 17 Mar 2020 17:54:47 +0000")
Simon Ser <contact@emersion.fr> writes:
> 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?
I think we are passing a struct pid through the socket metadata.
So it should be technically feasible.
However it does come with some long term mainteance costs.
The big question is what is a pid being used for when being passed.
Last I looked most of the justifications for using metadata like that
with unix domain sockets led to patterns of trust that were also
exploitable.
Looking at the proposale in [1] even if you have race free access
to /proc/<pid>/exe using pidfds it is possible to change /proc/<pid>/exe
to be anything you can map so that seems to be an example of a problem.
So it would be very nice to see a use case spelled out where
the pid reuse race mattered, and that trusting a pid makes sense.
I have to dash but I will think about this and see if I can give a
concrete example of using a capability model. Other than the current
one that works (handing out trusted sockets at the logical beginning of
time). Though frankly I am not certain there is anything much better
than that.
Eric
> Thanks,
>
> Simon Ser
>
> [1]: https://gitlab.freedesktop.org/wayland/weston/issues/206
> [2]: https://github.com/flatpak/flatpak/issues/2995
next prev parent reply other threads:[~2020-03-17 19:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-17 17:54 SO_PEERCRED and pidfd Simon Ser
2020-03-17 18:18 ` Christian Brauner
2020-03-18 10:16 ` Simon Ser
2020-03-18 12:21 ` Christian Brauner
2020-03-17 18:58 ` Eric W. Biederman [this message]
2020-03-18 10:31 ` Simon Ser
2020-03-18 11:56 ` Christian Brauner
2020-03-18 13:07 ` Eric W. Biederman
2020-03-18 13:43 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d09akduh.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=christian@brauner.io \
--cc=contact@emersion.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).