Invoking Commands When They Require Permissions

Running as root is dangerous, although sometimes convenient—especially when you are new to Linux and password prompts seem to be a hassle. So far, as a Linux user, you may have seen the sudo command or the su command. These commands can allow a user to change users on the system at the console or execute commands momentarily with higher permissions (if the user has sudo permissions). Sudo, or substitute user do, enables a regular user to escalate (raise) their user permissions to a more privileged level for a SINGLE command.

Alternatively, the substitute user command, or su, allows you to also run commands that are privileged and to even change shells (for example, to become a root user). Sudo doesn’t activate a root shell or allow you access to other user accounts, which is unlike the su command.

Here are some example uses of the two commands:

$ sudo ls /root 
$ su -c 'ls /root' 
$ su -

While both commands require knowledge of a root password, sudo also requires that the user executing the sudo command is listed in the /etc/sudoers file:

$ sudo /etc/sudoers 
[sudo] password for rbrash: 
# 
# This file MUST be edited with the 'visudo' command as root. 
# 
# Please consider adding local content in /etc/sudoers.d/ instead of 
# directly modifying this file. 
# 
# See the man page for details on how to write a sudoers file. 
# 
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:ALL) ALL 

# See sudoers(5) for more information on "#include" directives: 
#includedir /etc/sudoers.d

In the preceding standard Ubuntu sudoers file, we can see that the admin group of users can use the sudo command (and likely the reason you are able to do so as well without tinkering). We can also see that there can be specific user privilege execution:

root ALL=(ALL:ALL) ALL

This indicates that the root user can run all the commands available on the system. In fact, we could add a line for a user named rbrash, such as rbrash ALL=(ALL) ALL.

/etc/sudoers can be edited by a user with root permissions using the visudo command:

$ sudo visudo

Note:

Be careful when adding permissions or alterations to users. It could become a security risk if the account is not secure!

At the end of the day, you might wonder why this is so important for a Bash script (besides being able to escalate permissions). Well, imagine that you might have a system in place that performs Continuous Integration or a process that builds software continuously (for example, Jenkins)—it might just be desirable to have a build running various commands without your input, hence the use of giving a user access to specific commands (especially if they are sandboxed or within a virtual machine).

Prerequisites

Besides having a terminal open, we need to remember a few concepts:

• sudo requires a password (unless specified)
• sudo can also be limited to specific commands, users, or hosts
• sudo commands are also logged in either /var/log/secure or /var/log/auth.log:

Dec 23 16:16:19 moon sudo: rbrash : TTY=pts/2 ; PWD=/home/rbrash/Desktop/book ; USER=root ; COMMAND=/usr/bin/vi /var/log/auth.log 
Dec 23 16:16:19 moon sudo: pam_unix(sudo:session): session opened for user root by (uid=0)

Additionally, we can create a new user for this:

$ sudo useradd bob 
$ sudo passwd bob #use password

How to do it…

Let’s start our activity as follows:

Run the command in a new terminal, not as root, and without any previous sudo authorization:

$ shutdown -h 10 
$ shutdown -c

Now, execute the $ sudo visudo command and edit the script to include the following lines:

$ sudo visudo 
[sudo] password for rbrash: 
# 
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 

Cmnd_Alias READ_CMDS = /sbin/halt, /sbin/shutdown 

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

bob ALL=(ALL:ALL) NOPASSWD: READ_CMDS 

# 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:ALL) ALL 

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

#includedir /etc/sudoers.d

Run the command in a new terminal, not as root and without any previous sudo authorization:

$ shutdown -h 10 
$ shutdown -c

Notice anything different? Now, make sure to cancel the shutdown using the previous command: $ shutdown -c.

How it works…

The preceding recipe is pretty slim, but there is a fair bit of assumption and knowledge that you need to know about in regards to sudo. First, be careful. Second, be more careful. And finally, take care to keep your account secure with adequate password policies:

In step one, we tried to run two commands that require user permissions. Normally, rebooting or halting a system requires privilege escalation (unless done through the GUI). The shutdown -c command cancels a shutdown. If you used shutdown -h now, the system would shut down immediately. This cannot be stopped.

In the second step, we use the new visudo command to make edits to the /etc/sudoers file. In bold, Cmnd_Alias allows you define a group of commands, however, you have to use the full path of binaries. The user Bob is assigned to this Alias as well. NOPASSWD: is used to specify that the password is not required for these commands

In the third step, shutdown commands can be run without a password prompt.

The final step is to guarantee an accidental shutdown is cancelled.