I mean, this exact vulnerability is a counterexample. The input to pkexec is approximately (invoking user identity, program to run, arguments to pass to that program), and that’s all that would be provided over an IPC. The vulnerability here is in the contents of argv[0], which is not the input to the pkexec operation, just one of the values inherited through execve.

Now, I do acknowledge that the IPC server code could also be buggy, and it’s been historically difficult enough to write a good D-Bus server (with C, the old D-Bus libraries, possibly all that GObject boilerplate), that just slapping userhelper / pkexec on top of a CLI backend (or worse, a full GUI) was what ended up being implemented because it was so much easier and “worked well enough”.

But that’s “just” a matter of lack of investment — we know for decades that it’s possible to automate the IPC infrastructure (e.g. Java RMI, where one defines a Java interface type, a Java implementation of that interface, and just runs $tooling to run that interface implementation as an out-of-process server, in, what, 1998?), and to use memory-safe languages, to reduce human error and toil. After such an IPC infrastructure exists, for easy integration into clients and servers, it’s at least as easy to invoke an IPC, probably much easier, than encoding the IPC request as CLI parameters, and parsing them in the executed binary — especially when error handling needs to be taken into account.

Yeah, it would be a pretty big culture shift from the 1980s-UNIX approaches, and Open Source communities tend to be defined by their shared cultural values / design approaches.

So, just like moving from consolehelper to D-Bus APIs , in that linked bug from 12 years ago, it just didn’t happen, because the existing community was not inherently attracted to doing this kind of infrastructure work, and moving to “non-UNIXy” approaches.

    Mirek