Help me understand pkexec

[Goverp]

OK, it's not networks, so it must be security.

I've never bothered to look at pkexec before, but a discussion in last week's lwn.net triggered a read of man pkexec.
So, my current user is not a member of wheel, and so can't issue "su -", for example. I did that to reduce the attack surface from my "normal" desktop user.
I just tried

Code: Select all

pkexec cfdisk /dev/sda

That works: a window pops up to ask for root password. Irrespective of not being in wheel.
Oh, even worse. Just type

Code: Select all

pkexec

and after a prompt for root password, a root bash shell!

Am I misconfigured, or is this as horrible as it looks.

[eccerr0r]

misconfigured, but it's default configuration.

I thought at one point there was a polkit rule that required wheel but I think that was jettisoned. It was one "complexity" that was removed as people probably was complaining about it as basically all console users were required to be in 'wheel' to muck with network settings with networkmanager/nm-applet. I believe all console users now have pkexec at least run rights. Not sure if remote users are granted, I suspect not.

You can just disable pkexec for now if you're paranoid by removing setuid on it, but it would break anything that has pkexec integrated (virtman, udisks, gparted, networkmanager, ?). Else the proper fix is to reinstate that rule. Not sure if this https://askubuntu.com/questions/184085/ ... roup-wheel still applies as those directories no longer exist.

[figueroa]

I've never been able to get pkexec to work. There are two rules in /etc/polkit-1/rules.d

Code: Select all

$ cat 50-default.rules
/* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */

// DO NOT EDIT THIS FILE, it will be overwritten on update
//
// Default rules for polkit
//
// See the polkit(8) man page for more information
// about configuring polkit.

polkit.addAdminRule(function(action, subject) {
    return ["unix-user:0"];
});

$ cat 10-admin.rules
polkit.addAdminRule(function(action, subject) {
   if (subject.isInGroup("wheel")) {
       return polkit.Result.YES;
         }
	 });

and I AM in the wheel group. What can I change to get pkexec to work "by default?"

[Goverp]

I'd forgotten polkit was the horror that used Javascript as a way to extend the attack surface its configuration tool. I'll see what happens with:

Code: Select all

USE=-policykit emerge -pv --changed-use --deep @world

[Anon-E-moose]

I'd forgotten polkit was the horror that used Javascript as a way to extend the attack surface its configuration tool. I'll see what happens with:

Code: Select all

USE=-policykit emerge -pv --changed-use --deep @world

Polkit is not needed for much, it's typically there (in de environments, like gnome, kde, mate, etc.) to give the end user the ability to shutdown/hibernate/etc, the system (which needs root access). If you're comfortable with either running sudo or some other command and a script to do shutdown/whatever then there shouldn't be a problem.

I never used dm for starting my graphic sessions, I always booted into console and ran startx (I start wayland similarly now)
then when I was done with the session I go back to the command line and from there if I need to do privileged actions, I just use sudo or su.

Edit to add: just about every full DE has some type control center pkg, that typically requires polkit or something similar and it's typically required vs using a polkit use flag, so those wouldn't be built if you don't allow/use polkit. I always got around that by modifying the meta package and just not building the control center/whatever they call it.

[eccerr0r]

Don't forget mounting removable disks/loopback/crypto/device mapper to its own separate mount point, changing IP addresses and setting up bridges. I think most desktop environments try to add in seamless time/timezone changes as well as printer config changes (though not way too important with CUPS and it exposes its own possible holes) and these needs root too. Also some DEs have GUI hooks into configuring the display manger (gnome -> gdm) and this too needs root.

BTW sending a shutdown to /sbin/shutdown or /sbin/reboot does not give the DE a chance to tell all software monitoring shutdown commands to clean up and close their files before a kill ends up killing them prior to shutdown. While most software is OK you may want a second chance at hitting File-Save if needed: GUI integration allows for this.

figueroa, usually pkexec sort of tells you why it failed to get you root, that diagnostic message might be helpful. Having a session (elogind/systemd) and having dbus working is one thing. Also it tells you want specific resource it wants, which technically can be used to discern which to ask passwords for, always allow, always deny, etc. It also should log the reason for denial of access in the syslog or journal, this output might be helpful.

[pietinger]

Maybe these articles are helpful:
https://lwn.net/Articles/882799/
https://lwn.net/Articles/883547/

[figueroa]

...
figueroa, usually pkexec sort of tells you why it failed to get you root, that diagnostic message might be helpful. Having a session (elogind/systemd) and having dbus working is one thing. Also it tells you want specific resource it wants, which technically can be used to discern which to ask passwords for, always allow, always deny, etc. It also should log the reason for denial of access in the syslog or journal, this output might be helpful.

Thanks for the comments. I've been happy without pkexec except for being flumoxed at not being able to get it to work. Where I would ordinarily need pkexec to launch an application needing root authentication (i.e. gparted in the menu), I substitute ktsuss which works great. I am able to log out, restart, shutdown, etc from the desktop (OpenBox) without entering any authentication, so I know polkit is working.

Here are the relevant outputs.

Code: Select all

polkitd, elogind, dbus are all running:
 5404 ?        Sl     0:00 /usr/lib/polkit-1/polkitd --no-debug
 3409 ?        S      0:00 elogind-daemon
 3379 ?        Ss     0:03 /usr/bin/dbus-daemon --system
 9734 ?        S      0:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/openbox-session
 9735 ?        Ss     0:00 /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
 9799 ?        S      0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3

$ pkexec
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/bin/bash' as the super user
Authenticating as: root
Password: 
polkit-agent-helper-1: pam_authenticate failed: Permission denied
==== AUTHENTICATION FAILED ====
Error executing command as another user: Not authorized

This incident has been reported.
$

System log (metalog) /var/log/everything/current
Feb 11 23:09:05 [polkitd] Operator of unix-process:13359:60399492 FAILED to authenticate to gain authorization for action org.freedesktop.policykit.exec for unix-process:13359:60399492 [bash] (owned by unix-user:USERNAME)
Feb 11 23:09:05 [pkexec] USERNAME: Error executing command as another user: Not authorized [USER=root] [TTY=/dev/pts/1] [CWD=/home/USERNAME] [COMMAND=/bin/bash]
Feb 11 23:09:05 [polkitd] Unregistered Authentication Agent for unix-process:13359:60399492 (system bus name :1.837, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)

I changed my username to USERNAME in the lines of the log.

[eccerr0r]

Interesting, seems it simply does not like the root password submitted. Are you using USE=-pam? Is your password for root up to date with a modern crypt?

[figueroa]

Interesting, seems it simply does not like the root password submitted. Are you using USE=-pam? Is your password for root up to date with a modern crypt?

I'm USE flag +pam for everything where it's an option. I'm on the "default/linux/amd64/17.1/desktop (stable)" profile with no mention of pam in make.conf or package.use and emerge --info shows pam as a default USE flag.

I confess that I don't know how to discern "password for root up to date with a modern crypt." I think so. I'd be interested in finding out.

BTW, I have four systems where pkexec fails to work identically. My main desktop was setup in 2017. The oldest (an x86 box) in 2004.

ADDED: I think the answer to the encryption question is sha512:

Code: Select all

$ more /etc/pam.d/system-auth
auth		required	pam_env.so
auth		requisite	pam_faillock.so preauth
auth            [success=1 default=ignore]      pam_unix.so nullok  try_first_pass
auth		[default=die]	pam_faillock.so authfail
account		required	pam_unix.so
account         required        pam_faillock.so
password	required	pam_passwdqc.so config=/etc/security/passwdqc.conf
password	required	pam_unix.so try_first_pass use_authtok nullok sha512 shadow
session		required	pam_limits.so
session		required	pam_env.so
session		required	pam_unix.so

[eccerr0r]

and another "cover all bases" question: etc-update up to date?

Also just verified: if you ssh in, pkexec does not let you to login to root even if you know the root password. At least if you have seats working properly. (loginctl, and make sure you have a seat)

TBH I had several machines not work for a while when they first were migrated from not having a session manager to to consolekit/elogind/systemd, but after several updates they started working just fine...

[Hu]

I think modern crypt is in reference to this block from the glibc/libxcrypt news item:

Code: Select all

Please note that if you last changed your password before ~2008,                          
it may be using md5crypt or similar other weak mechanisms in /etc/shadow;                 
a bug in PAM [0][1] may mean that you were unable to login. We recommend
using "passwd" to change/refresh your password so it is using modern
methods. A new version of PAM has been added to the tree to resolve this issue.

You can tell which algorithm is used by checking the first few characters of that password in /etc/shadow. You want to see $6$. You do not want to see $1$.

[figueroa]

eccerr0r -- Yes, I update frequently and run etc-update (actually, dispatch-conf) when called for, and sometimes, just to check. With regard to ssh:

Code: Select all

$ sudo grep Root /etc/ssh/sshd_config
#PermitRootLogin prohibit-password

I don't think that is because of pkexec (?).

Hu -- also:

Code: Select all

$ sudo grep root /etc/shadow
root:$6$~

Yes, in both instances of sudo, I had to type a password, I just left that part out of the code tags.

The issue with pkexec is long standing on my machines where I don't tend to have issues. If you have pkexec working normally and polkit configuration file(s) you can share, I'd be pleased to try them out.

[eccerr0r]

Oh... no I actually mean when you're remotely connected (using ssh as an example) polkit will no longer allow you to pkexec by default, even if you know the correct password -- as I thought it would do as default behavior. Whether this is the way you want it to work is another question.

Just wanted to make sure if you are in your terminal and run loginctl you actually got a seat, else you might be thrown out like if I ssh in.

I do not have any configs other than the default /etc/polkit-1/rules.d/50-default.rules . /usr/share/polkit-1/rules.d is empty and /usr/share/polkit-1/actions/org.freedesktop.policykit.policy is default.

[figueroa]

eccerr0r: I didn't realize that about remote connections via ssh, which explains why the new MX-Linux won't complete updates when I access remote desktops using X2GO. That's OK, because those updates go fine in a remote shell the old way with apt-get.

But, on my main desktop computer, I'm sitting right in front of it, logged in via LightDM and running OpenBox (dbus, elogin and polkitd running), and testing pkexec in a terminal (LXTerminal and sakura).

[eccerr0r]

Sure you got a seat with the session and not just a session (loginctl)?

[figueroa]

I've got a seat:

Code: Select all

$ loginctl list
SESSION  UID USER     SEAT  TTY
     49 1000 USERNAME seat0

[eccerr0r]

hmm...weird, didn't get a tty?

[figueroa]

hmm...weird, didn't get a tty?

Not reported to that command, but the GUI is definitely on TTY7. Let's try this:

Code: Select all

$ loginctl session-status
49 - USERNAME (1000)
           Since: Sun 2022-02-13 12:00:52 EST; 7h ago
          Leader: 7292 (lightdm)
            Seat: seat0; vc7
         Display: :0
         Service: lightdm; type x11; class user
         Desktop: openbox
           State: active

[eccerr0r]

Could have sworn I had a TTY on my openrc-elogind boxes, but not handy right now. My systemd-logind boxes gives a TTY that's the actual /dev/____ (instead of just vc_).

Have to report back later when I have a desktop openrc box handy... sshing into one I get a TTY but no seat.

For now,
(systemd-logind, in X11 on console):

Code: Select all

$ loginctl
SESSION   UID USER SEAT  TTY 
      2  6969 USER seat0 tty5
     c2   102 gdm  seat0 tty1

(systemd-logind, logged in remotely with guest on console):

Code: Select all

$ loginctl 
SESSION   UID USER  SEAT  TTY  
    190  9696 guest seat0 tty5
    681  6969 USER        pts/0

(openrc-elogind, logged in remotely):

Code: Select all

$ loginctl
SESSION   UID USER SEAT TTY  
   3540  6969 USER      pts/2

[figueroa]

I have a solution/workaround. This thread stirred my interest, even though I've been living nicely without pkexec working.

The problem is that pkexec requires a polkit agent, with is usually provided by the desktop environment according to the Arch wiki: https://wiki.archlinux.org/title/Polkit ... ion_agents. But, I'm not running a desktop environment, just the window manager OpenBox.

lxde-base/lxsession installs lxpolkit, according to "man lxpolkit" is a PolicyKit agent. I can run lxpolkit without lxsession and it cleanly (no error messges) gives me access to pkexec. (I could also run lxsession, which starts lxpolkit, but one of the reasons I switched to just OpenBox was to not have that overhead.)

From the commandline, as an ordinary user, I can run "lxpolkit &" and then in that window or any other window I can run "pkexec" or "pkkexec command" and it gives me a nice gui authentication window in which to enter the user password.

I added "lxpolkit &" to ~/.config/openbox/autostart" as one of the last items started, and it appears to work beautifully. It seems very compatible with my GUI, since I'm using OpenBox with PCManFM to manage the desktop and LXPanel to provide the usual panel functions, and I'm very happy with this environment.

The burning issue for me is that on a day-to-day basis, I don't need pkexec. I probably won't keep lxpolkit in the ~/.config/openbox/autostart list for regular use, but comment it out and add the comment that it's needed to use pkexec.

Thanks eccerr0r and hu for participating in the discussion.

[eccerr0r]

Ah did that clean up the unauthorized agent error/warning? Hmm... That would explain that though thought it should say missing agent, normally it uses dbus to pull up the password prompt and fall back to tty prompt for the password (which it did). Been trying to get pkexec to work in a ssh session -- now that's another issue...

[figueroa]

The missing policykit agent was hinted at in one of the lines of an error logs I posted above:

Code: Select all

Feb 11 23:09:05 [polkitd] Unregistered Authentication Agent for unix-process:13359:60399492 (system bus name :1.837, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)

I did a lot of internet searching for different combinations of keywords, like polkit agent, policykit agent, pkexec agent. I think the latter one is which landed me on the Arch Wiki page.

Launching lxpolkit puts this line in /var/log/everything/current (metalog):

Code: Select all

Feb 14 13:39:41 [polkitd] Registered Authentication Agent for unix-session:109 (system bus name :1.399 [lxpolkit], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.utf8)

In a terminal, entering "pkexec" or "pkexec bash" the following is logged:

Code: Select all

Feb 14 13:43:13 [polkitd] Operator of unix-session:109 successfully authenticated as unix-user:USERNAME to gain ONE-SHOT authorization for action org.freedesktop.policykit.exec for unix-process:17633:16524360 [bash] (owned by unix-user:USERNAME)
Feb 14 13:43:13 [pkexec] pam_unix(polkit-1:session): session opened for user root(uid=0) by (uid=1000)
Feb 14 13:43:13 [pkexec] USERNAME: Executing command [USER=root] [TTY=/dev/pts/2] [CWD=/home/USERNAME] [COMMAND=/bin/bash]

If I ssh into my server, which has a working LXDE or OpenBox GUI, but none running, and try to run lxpolkit, I get an error:

Code: Select all

$ lxpolkit

(lxpolkit:22027): Gtk-WARNING **: 13:48:45.687: cannot open display:

If I x2go to my server in an OpenBox session, I can run lxpolkit in a terminal window and then I can use pkexec within that session, but not from another ssh session. Nor can I run a command with ktsuss from the ssh shell session.

Back to work for me.