Hi folks! For anyone who hasn't seen it yet - there's quite a kerfuffle today about a major security issue in polkit: https://arstechnica.com/information-technology/2022/01/a-bug-lurking-for-... turns out that ever since it was invented, `pkexec` has had a bug allowing for local root privilege escalation. Which is...bad. The issue and some of the comments around it prompted me to wonder - why is `pkexec` still a thing? Particularly, why is it still a thing we are shipping by default in just about every Fedora install? My best recollection is that pkexec was kinda a kludge to allow us to get rid of consolehelper: some apps weren't getting rewritten to the Right Way of doing things under policykit, they still just wanted to have the entire app run as root, and pkexec was a way to make that happen. But that was then, and this is now. Does anything in Workstation use pkexec? Does anything in KDE use it? I'm pretty sure (at least I really hope!) nothing in Server uses it. I don't think any of our documentation recommends its use for interactive execution of things as root (these days we tend to just specify `sudo` for that and assume the install has an admin user). Should we just split it out of the polkit package into a subpackage and stop shipping the subpackage on those editions/spins at least? If there's anything in other desktops still using it, it can grow a dependency on the subpackage... Am I forgetting some other reason we still need it? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ desktop mailing list -- desktop(a)lists.fedoraproject.org To unsubscribe send an email to desktop-leave(a)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/desktop@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

gksu and its ilk aren't substantially better than pkexec. A proper solution would be talking to a system service over dbus (or some other protocol).

On Wed, Jan 26, 2022 at 02:21:19PM -0800, Adam Williamson wrote: > My best recollection is that pkexec was kinda a kludge to allow us to > get rid of consolehelper: some apps weren't getting rewritten to the > Right Way of doing things under policykit, they still just wanted to > have the entire app run as root, and pkexec was a way to make that > happen. That sounds right to me too. I mean not "right", but what happened. I'd also love to get rid of the entire javascript configuration system. That's... more CVEs waiting to happen.

The issue and some of the comments around it prompted me to wonder - why is `pkexec` still a thing? Particularly, why is it still a thing we are shipping by default in just about every Fedora install?

* Lennart Poettering: > I mean, polkit has some issues, but I am pretty sure that "pkexec" is > not what I'd consider the big problem with it. Or to say this > differently: the whole concept of tools like > su/sudo/setpriv/runuser/suid binaries is questionnable: i.e. I am > pretty sure we'd be better off if we would systematically prohibit > acquiring privs through execve(), and instead focus on delegating > privileged operations to IPC services — but of course that would be > quite a departure from traditional UNIX. One issue is that it's harder to prevent other users from doing execve than it's denying them access to some IPC service. In this sense, SUID programs are more robust.

>> One issue is that it's harder to prevent other users from doing execve >> than it's denying them access to some IPC service. In this sense, SUID >> programs are more robust. > > Well, that's precisely the problem that PK was supposed to address, > but then it descended down the JS rabbit hole... Not sure if we are talking about the same thing. I meant flooding the local socket (or similar) with requests, not access control.

something needing *pkexec*. Though from what we've found in this thread, it seems like at least GNOME and KDE definitely do still need it. I'm not enough of a domain expert to know if it's realistic to rewrite everything in GNOME and KDE that relies on pkexec to use a different mechanism.