Sudo/polkit permissions not applied on cockpit

[tholeb]

Explain what happens

Hello, I want to limit a group's permissions by allowing only a subset of commands. To do so, I've created a sudoers file in /etc/sudoers.d/cockpit (with Ansible), here is the content:

# sudo for "%{{ ambx_group }}" : added by Ansible
Defaults:%{{ ambx_group }} !requiretty
%{{ ambx_group }} ALL=(ALL) NOPASSWD: /bin/systemctl restart httpd
%{{ ambx_group }} ALL=(ALL) NOPASSWD: /bin/systemctl start httpd
%{{ ambx_group }} ALL=(ALL) NOPASSWD: /bin/systemctl stop httpd

# Logs
%{{ ambx_group }} ALL=(ALL) NOPASSWD: /bin/journalctl *
%{{ ambx_group }} ALL=(ALL) NOPASSWD: /bin/cat /var/log/*,/bin/view /var/log/*,/bin/less /var/log/*
%{{ ambx_group }} ALL=(ALL) NOPASSWD: /bin/cat /run/log/journal/*,/bin/view /run/log/journal/*,/bin/less /run/log/journal/*

Note: the {{ ambx_group }} is a variable replaced by the group's name when server is deployed with Ansible.

The sudo file works like a charm, there is no errors, and I can restart/start/stop the httpd service in CLI, but not via Cockpit (I can't use the button). I tried applying the same config with Polkit (as the docs suggests):

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units") {
        if (subject.isInGroup("myGroup") && action.lookup("unit") == "httpd.service") {
            var verb = action.lookup("verb");
            if (verb == "start" || verb == "stop" || verb == "restart") {
                return polkit.Result.YES;
            }
        }
    }
});

And even with polkit, the button is disabled. I tried allowing sudo cockpit-bridge, but it gives the user full permissions, which is not what I want.

Am I doing something wrong ?

Note: I use an SSO (Kerberos) to log into cockpit,

Version of Cockpit

195

Where is the problem in Cockpit?

Services

Server operating system

CentOS 7

Server operating system version

3.10.0-1127.el7.x86_64

What browsers are you using?

Firefox

System log

May 16 17:26:31 server021.hostname cockpit-session[17223]: pam_sss(cockpit:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost=55.37.73.76 user=username@hostname
May 16 17:26:31 server021.hostname sssd[be[hostname]][1059]: Group Policy Container with DN [cn={923ED3F1-5E2B-4896-BD82-73A1D625AF53},cn=policies,cn=system,DC=dc,DC=dc] is unreadable or has unreadable or missing attributes. In order to fix this make sure that this AD object has following attributes readable: nTSecurityDescriptor, cn, gPCFileSysPath, gPCMachineExtensionNames, gPCFunctionalityVersion, flags. Alternatively if you do not have access to the server or can not change permissions on this object, you can use option ad_gpo_ignore_unreadable = True which will skip this GPO.See 'man ad_gpo_ignore_unreadable for details.' 
May 16 17:26:31 server021.hostname sssd[be[hostname]][1059]: Warning: user would have been denied GPO-based logon access if the ad_gpo_access_control option were set to enforcing mode.
May 16 17:26:31 server021.hostname cockpit-session[17223]: pam_ssh_add: Failed adding some keys
May 16 17:26:31 server021.hostname systemd-logind[1207]: New session 885 of user username@hostname.
May 16 17:26:31 server021.hostname systemd[1]: Started Session 885 of user username@hostname.
May 16 17:26:31 server021.hostname cockpit-session[17223]: pam_unix(cockpit:session): session opened for user username@hostname by (uid=0)
May 16 17:26:31 server021.hostname polkitd[20216]: Registered Authentication Agent for unix-session:885 (system bus name :1.14984 [cockpit-bridge], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale fr_FR.UTF-8)
May 16 17:26:32 server021.hostname dbus[974]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
May 16 17:26:32 server021.hostname systemd[1]: Starting Hostname Service...
May 16 17:26:32 server021.hostname dbus[974]: [system] Successfully activated service 'org.freedesktop.hostname1'
May 16 17:26:32 server021.hostname systemd[1]: Started Hostname Service.
May 16 17:26:33 server021.hostname realmd[15148]: client using service: :1.14987
May 16 17:26:33 server021.hostname realmd[15148]: holding daemon: :1.14987
May 16 17:26:33 server021.hostname polkitd[20216]: Operator of unix-session:885 FAILED to authenticate to gain authorization for action org.cockpit-project.cockpit.root-bridge for unix-process:17229:36800144 [cockpit-bridge] (owned by unix-user:username@hostname)
May 16 17:26:33 server021.hostname pkexec[17298]: username@hostname: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/run/user/1029254063] [COMMAND=/usr/bin/cockpit-bridge --privileged]
May 16 17:26:33 server021.hostname sudo[17310]: pam_sss(sudo:auth): authentication failure; logname=username@hostname uid=1029254063 euid=0 tty= ruser=username@hostname rhost= user=username@hostname
May 16 17:26:33 server021.hostname sudo[17310]: pam_sss(sudo:auth): received for user username@hostname: 7 (Authentication failure)
May 16 17:26:33 server021.hostname polkitd[20216]: Operator of unix-session:885 FAILED to authenticate to gain authorization for action org.fedoraproject.FirewallD1.all for unix-process:17313:36800367 [sh -c pkcheck --action-id org.fedoraproject.FirewallD1.all --process $$ --allow-user-interaction 2>&1] (owned by unix-user:username@hostname)
May 16 17:26:35 server021.hostname sudo[17310]: pam_sss(sudo:auth): authentication failure; logname=username@hostname uid=1029254063 euid=0 tty= ruser=username@hostname rhost= user=username@hostname
May 16 17:26:35 server021.hostname sudo[17310]: pam_sss(sudo:auth): received for user username@hostname: 7 (Authentication failure)
May 16 17:26:37 server021.hostname sudo[17310]: pam_sss(sudo:auth): authentication failure; logname=username@hostname uid=1029254063 euid=0 tty= ruser=username@hostname rhost= user=username@hostname
May 16 17:26:37 server021.hostname sudo[17310]: pam_sss(sudo:auth): received for user username@hostname: 7 (Authentication failure)
May 16 17:26:39 server021.hostname sudo[17310]: username@hostname : command not allowed ; TTY=unknown ; PWD=/run/user/1029254063 ; USER=root ; COMMAND=/bin/cockpit-bridge --privileged
May 16 17:26:40 server021.hostname PackageKit[9802]: get-updates transaction /810_aeedccaa from uid 1029254063 finished with success after 1054ms
May 16 17:26:41 server021.hostname PackageKit[9802]: get-updates transaction /811_edaeaedb from uid 1029254063 finished with success after 350ms

*I had to remove some informations (like username, hostname, ...), the rest is untouched*

[kyumin-lee-arraytech]

I confirm that I'm experiencing the same issue on Cockpit version 264.1 running on RHEL 9.

I added a test user "user" that does not belong to the wheel group, and instead I created a /etc/sudoers.d/user with visudo with the following line: user ALL=(ALL) /bin/cockpit-bridge --privileged

The file gives the "user" user permission to use "sudo" with only "/bin/cockpit-bridge --privileged". Trying to run any other command with sudo in a terminal fails, with the error message "Sorry, user user is not allowed to execute ...".

On Cockpit, however, I'm able to switch successfully to Administrative access, and perform all administrative tasks, such as those in the menus "Networking", "Accounts", and "Services". The tasks that can be performed are beyond what I thought I had allowed to the "user" user with the sudoer file. This is an unexpected behavior.

[kyumin-lee-arraytech]

The second portion about the PolicyKit rules not being observed is similar to the issues #17339, #16345, and #11003, as pointed out by @martinpitt ("Most cockpit pages don't do polkit checks").

[martinpitt]

@kyumin-arraytech : Allowing sudo access to cockpit-bridge is equivalent to full root access. It's the moral equivalent of allowing access to "bash". So this won't help you to do partial privileges -- these simply don't work with current Cockpit, soryr.

[kyumin-lee-arraytech]

Thanks for the confirmation, @martinpitt .

[tholeb]

Hello, thank you for your replies.

[martinpitt]

See explanation above, there is nothing further to do for this particular issue.

[foreignmouse]

I installed cockpit in Ubuntu 20.04.5, and checked its version is 215-1, and I followed a link to add a *.pkla file to enforce netdev to have privileges of modifying all networkmanager settings, and the user in netdev group is able to modify network settings on cockpit websole. But I tried Debian 12 (cockpit 287-1) or ubuntu 18 (cockpit 164) by using the same way, the cockpit UI can't allow this user to modify networkmanager settings, and I confirmed this user has the permissions to modify networkmanager "nmcli general permissions", I wonder why? and why this bug can't be fixed in other cockpit versions? and this bug belongs to cockpit only? doesn't matter with polkit?

[foreignmouse]

https://askubuntu.com/questions/1476888/is-it-possible-to-add-a-connection-by-nmcli-command-without-sudo