In Linux and other Unix-like operating systems, only the root user can run all commands and perform certain critical operations on the system such as install and update, remove packages, create users and groups, modify important system configuration files and so on.
However, a system administrator who assumes the role of the root user can permit other normal system users with the help of sudo command and a few configurations to run some commands as well as carry out a number of vital system operations including the ones mentioned above.
Alternatively, the system administrator can share the root user password (which is not a recommended method) so that normal system users have access to the root user account via su command.
sudo allows a permitted user to execute a command as root (or another user), as specified by the security policy:
- It reads and parses /etc/sudoers, looks up the invoking user and its permissions,
- then prompts the invoking user for a password (normally the user’s password, but it can as well be the target user’s password. Or it can be skipped with NOPASSWD tag),
- after that, sudo creates a child process in which it calls setuid() to switch to the target user
- next, it executes a shell or the command given as arguments in the child process above.
Below are ten /etc/sudoers file configurations to modify the behavior of sudo command using Defaults entries.
$ sudo cat /etc/sudoers
# # 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" Defaults logfile="/var/log/sudo.log" Defaults lecture="always" Defaults badpass_message="Password is wrong, please try again" Defaults passwd_tries=5 Defaults insults Defaults log_input,log_output
Types of Defaults Entries
Defaults parameter, parameter_list #affect all users on any host Defaults@Host_List parameter, parameter_list #affects all users on a specific host Defaults:User_List parameter, parameter_list #affects a specific user Defaults!Cmnd_List parameter, parameter_list #affects a specific command Defaults>Runas_List parameter, parameter_list #affects commands being run as a specific user
For the scope of this guide, we will zero down to the first type of Defaults in the forms below. Parameters may be flags, integer values, strings, or lists.
You should note that flags are implicitly boolean and can be turned off using the '!'
operator, and lists have two additional assignment operators, +=
(add to list) and -=
(remove from list).
Defaults parameter OR Defaults parameter=value OR Defaults parameter -=value Defaults parameter +=value OR Defaults !parameter
1. Set a Secure PATH
This is the path used for every command run with sudo, it has two importances:
- Used when a system administrator does not trust sudo users to have a secure PATH environment variable
- To separate “root path” and “user path”, only users defined by exempt_group are not affected by this setting.
To set it, add the line:
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
2. Enable sudo on TTY User Login Session
To enable sudo to be invoked from a real tty but not through methods such as cron or cgi-bin scripts, add the line:
Defaults requiretty
3. Run Sudo Command Using a pty
A few times, attackers can run a malicious program (such as a virus or malware) using sudo, which would again fork a background process that remains on the user’s terminal device even when the main program has finished executing.
To avoid such a scenario, you can configure sudo to run other commands only from a psuedo-pty using the use_pty
parameter, whether I/O logging is turned on or not as follows:
Defaults use_pty
4. Create a Sudo Log File
By default, sudo logs through syslog(3). However, to specify a custom log file, use the logfile parameter like so:
Defaults logfile="/var/log/sudo.log"
To log hostname and the four-digit year in the custom log file, use log_host and log_year parameters respectively as follows:
Defaults log_host, log_year, logfile="/var/log/sudo.log"
Below is an example of a custom sudo log file:
5. Log Sudo Command Input/Output
The log_input and log_output parameters enable sudo to run a command in pseudo-tty and log all user input and all output sent to the screen receptively.
The default I/O log directory is /var/log/sudo-io, and if there is a session sequence number, it is stored in this directory. You can specify a custom directory through the iolog_dir parameter.
Defaults log_input, log_output
There are some escape sequences are supported such as %{seq}
which expands to a monotonically increasing base-36 sequence number, such as 000001, where every two digits are used to form a new directory, e.g. 00/00/01 as in the example below:
$ cd /var/log/sudo-io/ $ ls $ cd 00/00/01 $ ls $ cat log
You can view the rest of the files in that directory using the cat command.
6. Lecture Sudo Users
To lecture sudo users about password usage on the system, use the lecture parameter as below.
It has 3 possible values:
- always – always lecture a user.
- once – only lecture a user the first time they execute sudo command (this is used when no value is specified)
- never – never lecture the user.
Defaults lecture="always"
Additionally, you can set a custom lecture file with the lecture_file parameter, type the appropriate message in the file:
Defaults lecture_file="/path/to/file"
7. Show Custom Message When You Enter Wrong sudo Password
When a user enters a wrong password, a certain message is displayed on the command line. The default message is “sorry, try again”, you can modify the message using the badpass_message parameter as follows:
Defaults badpass_message="Password is wrong, please try again"
8. Increase sudo Password Tries Limit
The parameter passwd_tries is used to specify the number of times a user can try to enter a password.
The default value is 3:
Defaults passwd_tries=5
To set a password timeout (default is 5 minutes) using passwd_timeout parameter, add the line below:
Defaults passwd_timeout=2
9. Let Sudo Insult You When You Enter Wrong Password
In case a user types a wrong password, sudo will display insults on the terminal with the insults parameter. This will automatically turn off the badpass_message parameter.
Defaults insults
Read More: Let Sudo Insult You When You Enter Incorrect Password
10. Learn More Sudo Configurations
Additionally, you can learn more sudo command configurations by reading: Difference Between su and sudo and How to Configure sudo in Linux.
That’s it! You can share other useful sudo command configurations or tricks and tips with Linux users out there via the comment section below.
Hello Aaron, thank you for sharing this info on sudo configuration. Is there a way for sudo to record tty commands run by a ldap user after sudo to a service account and store them to a file?
Example:
How would I let sudo store these commands (hostname, pwd, etc) to a file after a user sudo to service account (oracle, etc) and run commands as that service account on a server? I have an audit requirement on AIX 7.2 servers to capture all TTY session commands run by a user after sudo to a service account hosted on each server.
Thank you for your time.
Thank you.
@Ashok,
First, create a log directory and set the sticky bit on it.
Next, create a new script file under /etc/profile.d/ directory.
And add the below content at the bottom, save, and exit.
Set the permission and enable the script.
Now all user executed commands history saved to log file…
Hi Ravi,
Thank you so much for the quick response. Does the same procedure apply on AIX 7.2 servers since it uses Korn shell by default? I see that the /etc/profile.d directory does not exist on AIX servers and I have implemented step 1 by adding those lines in /etc/profile to set up secondary logging for root which looks good as the file was created, not sure if I should add commands to the same /etc/profile file to setup secondary logging for other users except root. Thank you.
@Ashok,
I think you can add those lines to /etc/profile and see if it is working or not…
This is a minor typo.
should be:
Fantastic. Thank you for this script.
@Aljjana,
Thanks, corrected the command in the script…
This is an excellent article. With this, I complement my knowledge about the root users and permissions.
@Ryan
Great! We are grateful that this has helped you gain more knowledge about Linux. Many thanks for the useful feedback.
Hi,
Thanks for the nice overview.
Can you help with this?
I want to mount a special source without root privileges. So I made an entry in the /ect/sudoers file:
How can I restrict the source that I want to mount to be only one that can be mounted. Now username can mount everything.
Thanks in advance.
Bye,
I think what you may want to do is, instead of using sudo, add the mount to /etc/fstab, and include the option “user” (see the man page on “mount”). What this will do is allow ordinary users to mount/unmount the filesystem. That would allow ALL users to mount/unmount it. They can then say “mount /mnt/folder“. This mount option is specific to Linux and would not work on other flavors of Unix.
Another option would be to use the automounter. You could setup a direct automount map. Then whenever a user does “cd /mnt/folder“, it mounts. After it mounts, every 5 minutes, it half-heartedly attempts to unmount it, which will not be successful if it is still in use. Again, this would allow ALL users to mount it.
If you really want just the one user to be able to mount/unmount, then you’d need to spell out the full mount command (not /sbin/mount.cifs):
user ALL = NOPASSWD: /bin/mount /path-to-device /mnt/folder, /bin/umount /mnt/folder
(there might be some options you’ll want to specify after “mount”, e.g. “-o ro”, “-t cifs”, etc.). The user will then need to type the command-line exactly as it appears in sudoers (if they are not that savvy, create them an alias).
@Garry
These are practically better solutions, well explained. Am also testing them. Thanks for sharing.