Re: SO_PEERCRED and pidfd

[Simon Ser]

On Tuesday, March 17, 2020 7:58 PM, <ebiederm@xxxxxxxxxxxx> wrote:

> Simon Ser contact@xxxxxxxxxxx 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.