polkit-agent-helper-1 is setuid root and runnable by ordinary users, does it need to be? #169
Comments
|
In gitlab.freedesktop.org by smcv on Feb 3, 2022, 01:45 Limitations of both the routes I suggested:
|
|
In gitlab.freedesktop.org by clx814727823 on Jul 19, 2022, 08:39
Why? I mean that, in fact, pam_unix.so will fork and exec unix_chkpwd, which have suid to check /etc/shadow. So why we need a suid helper at all? |
…t SETUID SETUID binaries are considered harmful, as te execution context is under the control of unprivileged attackers. Enhance the polkit pam agent helper with a new mode: when running under systemd, add a socket-activated service that the helper will run under, as root. The agent talks to this service via AF_UNIX instead of spawning it, and STDIN/STDOUT are connected as before. The helper can make use of PID FDs and SO_PEERCRED to reliably identify the caller. In order to do this, a third version of the auth D-Bus method is added, that also takes a subject, built using the PID FD. If the AF_UNIX socket is not present, the agent will fork the helper as before, with no changes. Fixes polkit-org#169
|
I've opted for a slight variation: the agent will talk directory to the socket-activated privileged helper via AF_UNIX, instead of going through a third intermediate binary. The privileged socket-activated helper will identify the caller via PID FD so that it is safe against reuse attacks. |
…t SETUID SETUID binaries are considered harmful, as te execution context is under the control of unprivileged attackers. Enhance the polkit pam agent helper with a new mode: when running under systemd, add a socket-activated service that the helper will run under, as root. The agent talks to this service via AF_UNIX instead of spawning it, and STDIN/STDOUT are connected as before. The helper can make use of PID FDs and SO_PEERCRED to reliably identify the caller. In order to do this, a third version of the auth D-Bus method is added, that also takes a subject, built using the PID FD. If the AF_UNIX socket is not present, the agent will fork the helper as before, with no changes. Fixes polkit-org#169
…t SETUID SETUID binaries are considered harmful, as te execution context is under the control of unprivileged attackers. Enhance the polkit pam agent helper with a new mode: when running under systemd, add a socket-activated service that the helper will run under, as root. The agent talks to this service via AF_UNIX instead of spawning it, and STDIN/STDOUT are connected as before. The helper can make use of PID FDs and SO_PEERCRED to reliably identify the caller. In order to do this, a third version of the auth D-Bus method is added, that also takes a subject, built using the PID FD. If the AF_UNIX socket is not present, the agent will fork the helper as before, with no changes. Fixes polkit-org#169
…t SETUID SETUID binaries are considered harmful, as te execution context is under the control of unprivileged attackers. Enhance the polkit pam agent helper with a new mode: when running under systemd, add a socket-activated service that the helper will run under, as root. The agent talks to this service via AF_UNIX instead of spawning it, and STDIN/STDOUT are connected as before. The helper can make use of PID FDs and SO_PEERCRED to reliably identify the caller. In order to do this, a third version of the auth D-Bus method is added, that also takes a subject, built using the PID FD. If the AF_UNIX socket is not present, the agent will fork the helper as before, with no changes. Fixes polkit-org#169
|
@poettering you said once run0 does not depend on a setuid binary. here is one left. |
In gitlab.freedesktop.org by smcv on Feb 2, 2022, 23:29
Link to the original issue: https://gitlab.freedesktop.org/polkit/polkit/-/issues/168
I've been thinking about ways to reduce setuid attack surface to avoid things like CVE-2021-4034 happening in the future.
polkit currently installs polkit-agent-helper-1, which is used by polkit agents to re-authenticate a user. This is typically done by running a PAM stack, which is required to be done as root and with privileges. The
-shadowimplementation bypasses PAM and reads/etc/shadowdirectly, which similarly requires privileges.setuid executables run in a hostile environment: a potential attacker controls every aspect of their execution environment (environment variables, argv, open fds, controlling terminal, signal dispositions...), and if setuid executable makes a security-sensitive assumption about any of those process parameters, an attacker might be able to exploit that.
One possibility to harden this would be to use systemd socket-activation to launch one instance of something functionally equivalent to the current polkit-agent-helper-1 (except not setuid, and with the user to authenticate written to its stdin instead of being passed in argv) per connection to a socket. libpolkit-agent-1 would run a separate non-setuid program, reusing the current polkit-agent-helper-1 filename for backwards compatibility, which would just connect to the socket and proxy the PAM conversation. Non-systemd systems would have to either continue to build and install a setuid polkit-agent-helper-1 (no improvement, but no regression either), or implement socket-activation with inetd or something.
Another possible route would be for the program that is run by libpolkit-agent-1 to be unprivileged, and just make a D-Bus call to polkitd, fd-passing a pair of pipes (or maybe a single AF_UNIX socket). polkitd could execute a setuid program (directly equivalent to the current helper) installed with
rwsr-x---permissions and owned byroot:polkitd(this would need a newpolkitdgroup, obviously), so that users other than polkitd cannot possibly exploit it via creative choices of execution environment. This is similar to the waydbus-daemon-launch-helperis setuid root, but only the system bus uid (typicallydbusormessagebus) can run it.(In old versions of polkit with less privilege-separation, this would ironically have been easier, because polkitd ran as root and so no setuid would have been required.)
This would also allow rate-limiting authentication attempts, if that's desirable: if using systemd socket activation, this would be systemd configuration, or if using D-Bus calls to polkitd, it would be up to polkitd.
The text was updated successfully, but these errors were encountered: