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-12-...
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?
Hi, GNOME System Monitor uses pkexec for doing tasks the user otherwise would be not allowed to do (kill process of other users, renice, etc). But pkexec is only the first option, support for gksu and gnomesu are theoretically also supported as fallbacks, but as far as I see these are not supported by major distros anymore (not supported meaning not provided, not installable).
I am eager to hear some suggestions on replacing pkexec-based solution, or maybe System Monitor should not be part of the default Fedora.
Regards, Robert
On Thu, Jan 27, 2022 at 12:39 AM Adam Williamson adamwill@fedoraproject.org wrote:
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-12-...
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@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@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.or... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Jan 27, 2022 at 1:19 AM Roth Robert robert.roth.off@gmail.com wrote:
Hi, GNOME System Monitor uses pkexec for doing tasks the user otherwise would be not allowed to do (kill process of other users, renice, etc). But pkexec is only the first option, support for gksu and gnomesu are theoretically also supported as fallbacks, but as far as I see these are not supported by major distros anymore (not supported meaning not provided, not installable).
I am eager to hear some suggestions on replacing pkexec-based solution, or maybe System Monitor should not be part of the default Fedora.
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 Thu, Jan 27, 2022 at 01:04:39PM -0500, Matthias Clasen wrote:
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).
Yeah, it's just that no one has published exploits for those yet. :)
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.
On Thu, Jan 27, 2022 at 1:05 PM Matthew Miller mattdm@fedoraproject.org wrote:
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.
Some years ago, Ikey Doherty made a patchset to allow polkit to use regular config files instead of JavaScript[1]. He did it in Solus[2], but the discussion upstream petered out and nothing happened. Maybe we could talk to Ikey about reviving it and integrating it upstream finally?
[1]: https://lists.freedesktop.org/archives/polkit-devel/2017-October/000547.html [2]: https://dev.getsol.us/T4824
Hi Adam,
also gvfs uses pkexec currently to start gvfsd-admin backend...
Regards
O.
st 26. 1. 2022 v 23:39 odesílatel Adam Williamson adamwill@fedoraproject.org napsal:
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-12-...
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@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@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.or... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mi, 26.01.22 14:21, Adam Williamson (adamwill@fedoraproject.org) wrote:
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?
I don't think there's too much wrong with pkexec. It's like sudo but with a much smaller, tighter footprint, with a hookup to intractive UI stuff. I am pretty sure many cases where sudo is used right now would actually benefit from using pkexec instead.
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.
I mean, if you buy into the conceptual idea that sudo/su/… are a good thing, and are fine with polkit, too, then I am pretty sure pkexec is actually the best option you have, and you should rather dump sudo.
"pkexec" is a *short* program, it runs very little code with privileges actually. That makes it a *ton* better than the humungous code monster that "sudo" is. It has a smaller security footprint, and is easier to review than "sudo". That's worth a lot actually.
Lennart
-- Lennart Poettering, Berlin
* 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.
Thanks, Florian
On Fr, 28.01.22 12:12, Florian Weimer (fweimer@redhat.com) wrote:
- 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.
Well, that's precisely the problem that PK was supposed to address, but then it descended down the JS rabbit hole...
Lennart
-- Lennart Poettering, Berlin
* Lennart Poettering:
On Fr, 28.01.22 12:12, Florian Weimer (fweimer@redhat.com) wrote:
- 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.
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.
Thanks, Florian
On Fr, 28.01.22 12:25, Florian Weimer (fweimer@redhat.com) wrote:
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.
Well, making socket services scalable is not entirely trivial, but i figure the number of parallel connections a Linux system should be able to handle is still higher than the number of processes it allows to run in parallel...
Lennart
-- Lennart Poettering, Berlin
On Fri, 2022-01-28 at 11:41 +0100, Lennart Poettering wrote:
"pkexec" is a *short* program, it runs very little code with privileges actually. That makes it a *ton* better than the humungous code monster that "sudo" is. It has a smaller security footprint, and is easier to review than "sudo". That's worth a lot actually.
...and yet despite being so easy to review it somehow had a major security vulnerability ever since it was written.
Anyway, my point is not really pkexec vs. sudo for interactive use, but whether pkexec is actually needed by default on all of our editions for non-interactive use. It's not an easy question to answer since our packaging doesn't distinguish between something needing *polkit* and 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.
On Fri, Jan 28, 2022 at 11:26:58AM -0800, Adam Williamson wrote:
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.
I wouldn't call myself a domain expert on this, but ... cc-remote-login-helper at least should be able to be updated. (It's making dbus calls to systemd to enable sshd.)
Other stuff may be more like fundamentally replacing the whole app/tool.
I wonder if a first step might be to split out pkexec into a subpackage, and then gradually remove requirements on it.
On Fr, 28.01.22 11:26, Adam Williamson (adamwill@fedoraproject.org) wrote:
On Fri, 2022-01-28 at 11:41 +0100, Lennart Poettering wrote:
"pkexec" is a *short* program, it runs very little code with privileges actually. That makes it a *ton* better than the humungous code monster that "sudo" is. It has a smaller security footprint, and is easier to review than "sudo". That's worth a lot actually.
...and yet despite being so easy to review it somehow had a major security vulnerability ever since it was written.
Yeah, but sudo is much worse, no? CVEs are a shitty metric, but afaik the number of CVEs of sudo dwarves the CVEs of pkexec...
Anyway, my point is not really pkexec vs. sudo for interactive use, but whether pkexec is actually needed by default on all of our editions for non-interactive use. It's not an easy question to answer since our packaging doesn't distinguish between something needing *polkit* and 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.
systemd's "ask-password" logic kinda pushes UI tools towards pkexec too btw.
Lennart
-- Lennart Poettering, Berlin
desktop@lists.fedoraproject.org
-
Adam Williamson -
Florian Weimer -
Lennart Poettering -
Matthew Miller -
Matthias Clasen -
Neal Gompa -
Ondřej Holý -
Roth Robert