Re: SO_PEERCRED and pidfd

From: Simon Ser <contact@emersion.fr>
To: "ebiederm@xmission.com" <ebiederm@xmission.com>
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: Wed, 18 Mar 2020 10:31:00 +0000	[thread overview]
Message-ID: <1Q35NFfgidxjWwXdBPA4EBehI5cyiQ2g47PjP_twMt_AlhcwWIzFK45Dyaw0bKT1KHPsbUAOXbfpvZODuRSd19LVI0tPBPsVblfSYy_YZEg=@emersion.fr> (raw)
In-Reply-To: <87d09akduh.fsf@x220.int.ebiederm.org>

On Tuesday, March 17, 2020 7:58 PM, <ebiederm@xmission.com> wrote:

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

/proc/<pid>/exe is a symlink. It doesn't seem like it's possible to
unlink it and re-link it to something else (fails with EPERM).

Is there a way to do this?

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

The use-case is identifying which process is at the other end of the
socket. Once the process is identified, security rules can be applied.
For instance a Wayland compositor might give access to a
screen capture interface if the program is a trusted screen shooter.

Some want to get the full path to the executable, and read the
/proc/<pid>/exe symlink. Some want to read a special file created at
the root of the process' file system namespace, and access
/proc/<pid>/root.

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