sudo restrictions circumvention with pkexec: root shell

Question

I had corrupted my sudo setup. With no possibility to login as root (locked root account, broken sudo), a search made it clear: use pkexec. It worked. So far, so good.

But that turns out to be a big security hole: a user that is part of the 'sudo' group can always gain root access, and start a shell as the root user. That is, at least on a default Ubuntu server installation with sudo.

This renders sudo useless as a means to restrict elevated privileges to certain commands for selected users. Unless some policykit policy is altered, apparently. That's not mentioned in the man pages of 'visudo' or 'sudo'. And I've never seen it mentioned in any tutorial on how to set up the sudoers file (probably I've been reading the wrong tutorials, then).

Can anyone point me into the right direction? What policykit, or sudo, configuration file needs to be changed (and how) in order to accommodate privilege escalation for one specific command, for one specific user?

As an example, I want the 'sudotest' user to only be able to run the command 'cat /proc/tty/driver/serial' which results in a 'Permission denied' error for non-privileged users.

Setup:

• Ubuntu bionic
• user 'sudotest', part of 'sudo' group
• either: single sudo command for 'sudotest', or even none

me@some-server:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:    18.04
Codename:   bionic

me@some-server:~$ ls -l /home
total 20
drwx------ 6 me  me   4096 May 17 15:17 me
drwx------ 2 root root 16384 Nov 26 17:20 lost+found

me@some-server:~$ sudo cat /etc/sudoers | grep -v "^#\|^$"
Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
root    ALL=(ALL:ALL) ALL
me  ALL=(ALL:ALL) ALL
%admin ALL=(ALL) ALL

me@some-server:~$ sudo useradd -m -d /home/sudotest -s /bin/bash sudotest

me@some-server:~$ sudo gpasswd -a sudotest sudo
Adding user sudotest to group sudo

me@some-server:~$ sudo passwd sudotest
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

me@some-server:~$ su - sudotest
su - sudotest
Password:

me@some-server:~$ $ groups
sudotest sudo

sudotest@some-server:~$ sudo -l
[sudo] password for sudotest: 
Sorry, user sudotest may not run sudo on some-server.

Hey, this user can not even do anything with sudo. Looks like an unprivileged user. Still, this user is perfectly capable of gaining a root shell using pkexec.

How can I prevent this? What configuration options do I have to allow this user to execute one single command of my choosing with elevated privileges?

---

Update: This is different from the linked question in that I want to know how I can (safely) limit a specific user to be able to execute one specific command with elevated privileges with sudo on a system that has polkit installed by default, which, apparently, allows any sudo user to gain a root shell.

Answer 1

a big security hole: a user that is part of the 'sudo' group can always gain root access, and start a shell as the root user. That is, at least on a default Ubuntu server installation with sudo.

This renders sudo useless as a means to restrict elevated privileges to certain commands for selected users.

As far as I know that is no actual security problem, except maybe in your expectations. Your conclusion is completely unwarranted.

1. Since Ubuntu 12.04 administrator access is granted via the "sudo" group.

2. Administrators need full and unrestricted superuser access to be able to perform their tasks.

3. This policy is consistently implemented in the default policies shipped by Ubuntu for both sudo and polkit, which allow all sudo group members to run both commandline and graphical applications as root.

(You then modified /etc/sudoers to remove the default policy for sudo group members but didn't modify the polkit policy. That led you to the mistaken conclusion that a member of the sudo group looks like unprivileged user, when they are (still) administrators with respect to other authentication systems. )

The solution is of course also obvious:

4. Don't make users a member of the sudo group when you don't want to grant them full superuser access.

5. For limited superuser access you will have to create your own policies in either sudo, polkit or both. You should create specific policies for particular users, or create new groups of your own for group based access controls.