Re: SO_PEERCRED and pidfd

[ebiederm@xmission.com (Eric W. Biederman)]

Simon Ser <contact@emersion.fr> writes:

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

prctl(PR_SET_MM_MAP, ...);
It is locked down a bit but not enough to trust it in general.

Further there are games I can play with ptrace where I can start an
executable and control it, so that you think it is the expected
executable calling the shots, when in fact it is the process acting
as the debugger performing the work.

Plus there are the other million and ways known to hijack a setuid
executable which also apply to this executable you would trust
because of it's exe_link.

Even beyond that to have a trusted process it's entire life cycle needs
to be trusted, so that you don't have the danger of someone unscrupulous
hijacking the process with bad input.

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

Once we reach the point of having a special file, it is much better
to pass that special file.  Or possibly something derived from the
special file in a zero knowledge proof sort of way, to prove you
are a trusted process.

Passing a file descriptor as a token the process is the trusted
process, is a perfectly fine way to provide proof and unix
domains sockets have supported that from day one.

I don't see how inspection of a process could make anything
better than having the process provide something, and I think it could
be even worse.

Eric