On Wed, 28 Jul 2021 11:05:11 +0000 Simon Ser <cont...@emersion.fr> said:
> On Wednesday, July 28th, 2021 at 12:30, Carsten Haitzler > <ras...@rasterman.com> wrote: > > > On Wed, 28 Jul 2021 09:51:53 +0000 Simon Ser cont...@emersion.fr said: > > > > > Please read the (lengthy) discussion at 1. > > > In particular, the "get_credentials → PID → executable path" lookup is > > > racy. PID re-use allows a malicious process to be recognized as another > > > executable. > > > > That is true - but only at cusp points - e.g. PID has exited, but socket has > > not been detected as dead yet and PID was recycled. I you do the lookup > > then, it'd be a problem. > > > > If you do the lookup first on initial connect, then ensure you do at least > > one round-trip to client (send something, it sends back a reply), then that > > lookup would be valid > > Nope. The PID returned by libwayland is the one that bound the socket. > So if you create the socket, fork, bind it in the child, exit the > child, then on the compositor side you'll see a socket which belongs to > a PID which no longer exists. Wait until a privileged client re-uses > that PID, and boom. oooh i see. the rogue process waits for a lucky pid replace. it can set this up. i was going to say "forking and keeping your fd alive is madness and unless you have a very funky thing you generally close the fd before passing it off to any child eg between fork and the exec". but yes - this can be abused to wait for ANOTHER unrelated privileged client to slide into that pid slot. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
