4

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.

6
  • You need to add * in commands. %sudo ALL=(ALL) NOPASSWD:/usr/bin/apt *,/usr/bin/apt-key *,/usr/bin/apt-add-repository *,/usr/bin/make * Commented Nov 12, 2019 at 14:08
  • 2
    This gives an syntax error in the sudoers file, also as far as I understand all options, i.e. command line arguments for binaries should automatically be allowed when the binary is listed. I think you only need to specify command line arguments if you additionally want to restrict the executable to certain options.
    – Invarianz
    Commented Nov 12, 2019 at 14:22
  • visudo gives no errors(Ubuntu 18.04) but you are correct, * is not needed Commented Nov 12, 2019 at 14:32
  • This is so strange since I install a 19.10 and paste your line it just works... Commented Nov 12, 2019 at 15:02
  • 1
    This is the solution, to mitigate a command line problem regarding sudo and aliases I added this to my .bash_aliases: alias sudo='sudo env "PATH=$PATH" '. This was to help with some proprietary piece of software, that was not installed in the standard path. I changed it back to alias sudo='sudo ' and now it works. I would gladly accept your answer.
    – Invarianz
    Commented Nov 12, 2019 at 15:30

1 Answer 1

3

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.

1
  • Thanks a lot for the really elaborate and enlightening answer. I am aware that the NOPASSWD makes the system less secure. I am not trying to lock out users from binaries but lock myself out from tampering with certain files. I try to keep an eye on my productivity and make it difficult to cheat, that is why I keep an elaborate /etc/hosts file that locks out most junk. By having a non memorable superuser password that I keep away while working and locking myself out from simply changing or moving the file with sudo privileges I can make it much harder and still do basic system maintenance.
    – Invarianz
    Commented Nov 12, 2019 at 19:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .