As there seem to be misunderstandings about what polkit is:
It's a way to let user processes communicate with privileged processes while potentially, action dependent also prompting the user for a password.
pkexec on the other hand is separate program bundled with polkit which is kinda which let's you combine polkit with running predefined commands, or easily accidentally any command and IMHO should not exist.
there are various programs which work with polkit (even if they don't necessary require it) including:
- systemd, logind, NetworkManager, udisks, flatpack, fwupd, timedate(setting), and others
It also allows rather flexible configurations about what users can do which actions under which conditions, which can be quite useful for a multi-user server (e.g. GPU server).
While I think a program like polkit is a must have for a modern Linux OS I'm not a fan of it's design.
- pkexec is a bad idea for many more reasons then this vulnerability
- the way it's configured and how it handles caching is prone to accidentally make mistakes with security consequences
- pkexec should not exist, even without the vulnerability it's really easy to mess up using it
- having a embedded language for handling permission scripting, and not inventing your own language or pseudo-language config format is a good. But js? I guess there are simple embedded js interpreters.(1)
(1): Note that it only runs small snippets, so no need to have a JS interpreter with modern features like classes, or an JIT ;=)
Speaking of security though, I'd trust SpiderMonkey much more because it's battle-tested in the most hostile environment imaginable (millions of browser instances loading completely untrusted code 24/7). But in this context we don't execute untrusted code so whatever :)
> pkexec should not exist
Hmm. For things that do want "just a graphical sudo" for whatever reason, it is kinda the perfect answer. Reusing the per-desktop authorization UI that is used for more fine-grained actions for a sudo-like tool is the correct thing to do. No one wants to have more redundant authorization mechanisms and UIs…
Ok, let me correct myself, `pkexec` as a simple GUI sudo should probably exist. But be differently designed.
(I would have to read through the polkit doc again, but there was some massive trap around how polkit configs work and how pkexec _might_ be used, I think related to the "permission caching feature").
> I'd trust SpiderMonkey much more because it's battle-tested in the most hostile environment imaginable
Enough OSes are behind and everyone using spidermonkey is unable to keep up with the porting requirements in the short window of ESR overlap so you can read vulnerabilities for the latest ESR and apply them to everyone. It would be nice if duktape had complete sandboxing, etc, but it has the advantage that hackers have to do all their own research to mount an attack.
sudo/suo/doas do not allow for flexible policy evaluation. They're also useless for GUI applications.
For instance, GNOME Settings uses PolKit to ensure that remote control can only be turned on by an admin who makes the request from an active session on a local console.
Or here's a more interesting example. gvfs uses PolKit to allow processes that are part of an active session on a local console to be able to elevate permissions for editing files (e.g., 'gedit admin:///etc/motd').
It's a way to let user processes communicate with privileged processes while potentially, action dependent also prompting the user for a password.
pkexec on the other hand is separate program bundled with polkit which is kinda which let's you combine polkit with running predefined commands, or easily accidentally any command and IMHO should not exist.
there are various programs which work with polkit (even if they don't necessary require it) including:
- systemd, logind, NetworkManager, udisks, flatpack, fwupd, timedate(setting), and others
It also allows rather flexible configurations about what users can do which actions under which conditions, which can be quite useful for a multi-user server (e.g. GPU server).
While I think a program like polkit is a must have for a modern Linux OS I'm not a fan of it's design.
- pkexec is a bad idea for many more reasons then this vulnerability
- the way it's configured and how it handles caching is prone to accidentally make mistakes with security consequences
- pkexec should not exist, even without the vulnerability it's really easy to mess up using it
- having a embedded language for handling permission scripting, and not inventing your own language or pseudo-language config format is a good. But js? I guess there are simple embedded js interpreters.(1)
(1): Note that it only runs small snippets, so no need to have a JS interpreter with modern features like classes, or an JIT ;=)