3 ms·

pkexec is a setuid binary because pkexec is just a sudo-alike that uses polkit for authorization. > a scheme of having a privileged service that acts on the re

pkexec is a setuid binary because pkexec is just a sudo-alike that uses polkit for authorization. > a scheme of having a privileged service that acts on the requests of unprivileged processes That is precisely what polkit is!

Klasiaster 5y ago
Nope because pkexec already is a privileged process because it is a setuid binary. Being a setuid binary instantly makes it a privileged process, it's not related to whether it's similar to sudo and does authorization. What I'm saying is that the pkexec process itself doesn't need to be setuid, it should be an unprivileged process (also true for the /usr/libexec/polkit-agent-helper-1 helper it uses which is a setuid binary but doesn't really have to be when splitting this up in a daemon process). Edit: Maybe to make it clear, yes, in theory the polkit project does follow the scheme of a privileged daemon process and unprivileged clients but in practice it doesn't because of the setuid polkit-agent-helper-1 and setuid pkexec programs.
- floatboth 5y ago
  It is a setuid binary because it does sudo. You cannot accomplish sudo without setuid. Note that sudo means gaining privilege in the current context, with all its environment (including inherited file descriptors, the process group, etc.), not doing a privileged action at a distance. > also true for the /usr/libexec/polkit-agent-helper-1 helper it uses which is a setuid binary but doesn't really have to be Try making it non-setuid and see what happens. (It will fail to check your password because most mechanisms for doing so, like the usual pam_unix, are only accessible to root.)
  - Klasiaster 5y ago
    > You cannot accomplish sudo without setuid. Right, process group and being child process gets lost when following this route. I think it's a compromise that is acceptable in many cases. > [polkit-agent-helper-1] will fail to check your password because most mechanisms for doing so, like the usual pam_unix, are only accessible to root.) That's what I mean, the helper itself could be unprivileged and hand the password over to a privileged daemon that does the check.
    - shawnz 5y ago
      If you make the interface between unprivileged client and privileged server too complicated, eventually it will be more complicated than the interface of executing a setuid binary and potentially more likely to have bugs
    - Klasiaster 5y ago
      Here for the pkexec/sudo case done using systemd-run - the script is similar to sudo and doesn't need to be setuid: https://gist.github.com/pothos/73dd4f7694acc3b6bbed614438f6e2b1 https://gist.github.com/pothos/73dd4f7694acc3b6bbed614438f6e...

Klasiaster 5y ago

Nope because pkexec already is a privileged process because it is a setuid binary. Being a setuid binary instantly makes it a privileged process, it's not related to whether it's similar to sudo and does authorization. What I'm saying is that the pkexec process itself doesn't need to be setuid, it should be an unprivileged process (also true for the /usr/libexec/polkit-agent-helper-1 helper it uses which is a setuid binary but doesn't really have to be when splitting this up in a daemon process). Edit: Maybe to make it clear, yes, in theory the polkit project does follow the scheme of a privileged daemon process and unprivileged clients but in practice it doesn't because of the setuid polkit-agent-helper-1 and setuid pkexec programs.

floatboth 5y ago
It is a setuid binary because it does sudo. You cannot accomplish sudo without setuid. Note that sudo means gaining privilege in the current context, with all its environment (including inherited file descriptors, the process group, etc.), not doing a privileged action at a distance. > also true for the /usr/libexec/polkit-agent-helper-1 helper it uses which is a setuid binary but doesn't really have to be Try making it non-setuid and see what happens. (It will fail to check your password because most mechanisms for doing so, like the usual pam_unix, are only accessible to root.)
- Klasiaster 5y ago
  > You cannot accomplish sudo without setuid. Right, process group and being child process gets lost when following this route. I think it's a compromise that is acceptable in many cases. > [polkit-agent-helper-1] will fail to check your password because most mechanisms for doing so, like the usual pam_unix, are only accessible to root.) That's what I mean, the helper itself could be unprivileged and hand the password over to a privileged daemon that does the check.
  - shawnz 5y ago
    If you make the interface between unprivileged client and privileged server too complicated, eventually it will be more complicated than the interface of executing a setuid binary and potentially more likely to have bugs
  - Klasiaster 5y ago
    Here for the pkexec/sudo case done using systemd-run - the script is similar to sudo and doesn't need to be setuid: https://gist.github.com/pothos/73dd4f7694acc3b6bbed614438f6e2b1 https://gist.github.com/pothos/73dd4f7694acc3b6bbed614438f6e...