sudoers file: allow sudo group execution of only certain binaries

Question

I'm trying to restrict the sudo group on my Ubuntu 19.10 install to only a certain assortment ouf executables.

The sudoers file now has the following form:

Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
#%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL) NOPASSWD: /usr/bin/apt,/usr/bin/apt-key,/usr/bin/apt-add-repository,/usr/bin/make

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Sadly the programs can still not be executed with the error message e.g. for apt update:

Sorry, user ubuntuuser is not allowed to execute '/usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin apt update' as root on Ubuntumachine.

If I add /usr/bin/env to the executable list I can again execute every and not only the restricted list of commands with sudo.

Answer 1

As you found, a shell alias made it so every command you ran with sudo ran the command through env, rather than directly.

After you edited /etc/sudoers to restrict what commands members of the sudo group could run, all sudo commands reported that you were not allowed to run env. So for some reason, every time you ran sudo command, it attempted to run the command with env. Furthermore, the error message always took this exact form:

Sorry, user ubuntuuser is not allowed to execute '/usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin command' as root on Ubuntumachine.

Using env in this way is a common technique for making sudo use your $PATH rather than the value of its secure_path option. Some users define a shell alias or shell function called sudo to make sudo command run something like that. In Bash, running type -a sudo would show everything the sudo command might mean, with the meaning the shell chooses shown first. (type sudo would show just that one.)

Having recalled the alias you defined, you were able to solve the problem by changing the alias not to use env. Removing the alias altogether would, of course, also work.

---

With that said, I encourage you to consider not using this sudoers configuration, because it has no security benefit compared to the default configuration. Actually it is somewhat less secure than the default configuration.

The main problem is that, while you appear to intend the line

%sudo   ALL=(ALL) NOPASSWD: /usr/bin/apt,/usr/bin/apt-key,/usr/bin/apt-add-repository,/usr/bin/make

to constrain what commands members of the sudo group can run, access to those commands is sufficient to perform any action whatsoever. As an example of how this is so--and this is just one example--a member of the sudo group could create the following Makefile:

.PHONY: elevate
elevate:
    su -

Then running sudo make gives a root shell with the same effect as successfully logging in as root. (Or su - could be replaced with another command, such as visudo to facilitate editing the sudoers file back. Or they could run visudo from the root shell given by su -.)

This cannot be solved by restricting what arguments are passed. In this case, make itself receives no command-line arguments.

The other commands you're allowing members of the sudo group to run are also sufficient to gain full access to the system. Even apt alone is enough to let users install whatever software they want, including software that is not from any configured repository (apt install ./package.deb). It is not hard to make one's own .deb package, and (among other lines of attack) .deb packages can include scripts that run as root at the time installation is performed.

And then there is Polkit. If this is a desktop system, Polkit in Ubuntu is configured to allow members of the sudo group to run arbitrary commands as root:

pkexec command

Even though it is configured by default to confer abilities to members of the sudo group, pkexec is unaffected by the contents of sudoers files.

This is less of a problem, at least in theory, in that you could reconfigure Polkit.

The reason I say your configuration is less secure than the default is that you are using NOPASSWD. This means that any program running as a member of the sudo group can perform any action whatsoever as root, without requiring any user interaction.

The security implications of NOPASSWD, though considerable, are sometimes overstated. After all, an attacker who gains control of a program run by a member of the sudo group can already put a fake sudo utility in place (for example, with the aid of an alias or shell function) and capture the user's password. That is likely to succeed. But it's a hassle, and it is not instant. NOPASSWD removes this hassle. You may decide you want to do that, but I recommend considering the risks carefully, especially if this is a multi-user system (which it sounds like it is).

---

From the commands you want to allow members of the sudo group to run, it sounds like those users really do serve roles in administering the system. That makes sense--after all, if they didn't, they would presumably not be members of the sudo group. Even within the "spirit" of your sudoers configuration, they can enable arbitrary repositories, install arbitrary software from them systemwide, and I presume letting them run make as root is so they can do the same with software they compile from source with commands like sudo make install.

If you fully trust the members of the sudo group (or perhaps it's just you) but just want to make it harder for them to do wrong things by accident, then one approach might be to give them separate accounts that are not in the sudo group, for tasks that don't require that they sudo to root.

If you don't trust them, then it is unlikely that there is a technical solution. Even if you were to lock down their abilities far more, it wouldn't be enough. The ability to control what software exists on the whole system, for use by all users, is always equivalent to the ability to perform arbitrary actions as root.