po 31. 1. 2022 v 13:49 odesílatel Sam Varshavchik <mr...@courier-mta.com>
napsal:
> And in both cases, the issue is the nature of the actual bug in the
> exploitable program, and not anything else. Suid is just a scapegoat.
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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
