agent helper: support separate socket-activated service to run without SETUID#501
Conversation
adcc469 to
f2206c2
Compare
…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
f2206c2 to
4672245
Compare
|
@jrybar-rh gentle ping |
Gentle ack. Though, I probably won't have time to review this till mid-Jan. But I will try to get to this asap. |
| @@ -113,7 +127,47 @@ main (int argc, char *argv[]) | |||
| goto error; | |||
| } | |||
|
|
|||
There was a problem hiding this comment.
Hi Luca, formally it all looks good, thanks for the hard work! Just to clear out the purpose, we still have a SUID binary (because of pam stack), but at least it runs in systemd-sandbox, right?
There was a problem hiding this comment.
Thanks! The SUID bit can be removed from the agent binary, and things should work without it on systemd systems. I have left support for the SUID mode in, for legacy systems that don't have socket activation
There was a problem hiding this comment.
Socket activation is manual on purpose, or WantedBy is missing?
There was a problem hiding this comment.
It's manual on purpose on the service, as that is only triggered by the socket unit
There was a problem hiding this comment.
But the socket has to be manually started first so the new code takes effect. I've just tried that on a fresh VM.
Just asking. I've got no problem adding a line in %post in rpm spec.
There was a problem hiding this comment.
Yes the socket unit itself has a WantedBy
There was a problem hiding this comment.
True, I had it right before my eyes. On the first run on VM, something weird happened and the polkit helper service unit failed after boot for some reason, so I started to wonder... It went all good on second provision.
Polkit v127 no longer requires a SUID `polkit-agent-helper-1` and instead recommends using a socket-activated `polkit-agent-helper` service[1]. [1] <polkit-org/polkit#501>
Polkit v127 no longer requires a SUID `polkit-agent-helper-1` and instead recommends using a socket-activated `polkit-agent-helper` service[1]. [1] <polkit-org/polkit#501>
Polkit v127 no longer requires a SUID `polkit-agent-helper-1` and instead recommends using a socket-activated `polkit-agent-helper` service[1]. [1] <polkit-org/polkit#501>
Polkit v127 no longer requires a SUID `polkit-agent-helper-1` and instead recommends using a socket-activated `polkit-agent-helper` service[1]. [1] <polkit-org/polkit#501>
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 #169