The dangers of logging in as the root user
A huge advantage that Unix and Linux operating systems have over Windows is that Unix and Linux do a much better job of keeping privileged administrative accounts separated from normal user accounts. Indeed, one reason that older versions of Windows were so susceptible to security issues, such as drive-by virus infections, was the common practice of setting up user accounts with administrative privileges, without having the protection of the User Access Control (UAC) that’s in newer versions of Windows. (Even with UAC, Windows systems still do get infected, just not quite as often.) With Unix and Linux, it’s a lot harder to infect a properly configured system.
You probably already know that the all-powerful administrator account on a Unix or Linux system is the root account. If you’re logged in as the root user, you can do anything you want to do to that system. So you may think, “Yeah, that’s handy, so that’s what I’ll do.” However, always logging in as the root user can present a whole load of security problems. Consider the following. Logging in as the root user can do the following:
- Make it easier for you to accidentally perform an action that causes damage to the system
- Make it easier for someone else to perform an action that causes damage to the system
So if you always log on as the root user, or even if you just make the root user account readily accessible, you could say that you’re doing a big part of attackers’ and intruders’ work for them. Also, imagine if you were the head Linux administrator at a large corporation, and the only way to allow users to perform admin tasks was to give them all the root password. What would happen if one of those users were to leave the company? You wouldn’t want that person to still have the ability to log in to the systems, so you’d have to change the password and distribute the new one to all of the other users. And what if you just want users to have admin privileges only for certain tasks, instead of having full root privileges?
What we need is a mechanism that allows users to perform administrative tasks without incurring the risk of having them always log on as the root user, and that would also allow users to have only the admin privileges they really need to perform a certain job. In Linux and Unix, we have that mechanism in the form of the sudo utility.
The advantages of using sudo
Used properly, the sudo utility can greatly enhance the security of your systems, and it can make an administrator’s job much easier. With sudo, you can do the following:
- Assign certain users full administrative privileges, while assigning other users only the privileges they need to perform tasks that are directly related to their respective jobs.
- Allow users to perform administrative tasks by entering their own normal user passwords so that you don’t have to distribute the root password to everybody and his brother.
- Make it harder for intruders to break into your systems. If you implement sudo and disable the root user account, would-be intruders won’t know which account to attack because they won’t know which one has admin privileges.
- Create sudo policies that you can deploy across an entire enterprise network, even if that network has a mix of Unix, BSD, and Linux machines.
- Improve your auditing capabilities because you’ll be able to see what users are doing with their admin privileges.
With regard to that last bullet point, consider the following snippet from the secure log of my CentOS 7 virtual machine:
Sep 29 20:44:33 localhost sudo: donnie : TTY=pts/0 ; PWD=/home/donnie ; USER=root ; COMMAND=/bin/su - Sep 29 20:44:34 localhost su: pam_unix(su-l:session): session opened for user root by donnie(uid=0) Sep 29 20:50:39 localhost su: pam_unix(su-l:session): session closed for user root
You can see that I used su - to log in to the root command prompt and that I then logged back out. While I was logged in, I did several things that require root privileges, but none of that got recorded. What did get recorded though is something that I did with sudo. That is, because the root account is disabled on this machine, I used my sudo privilege to get su - to work for me. Let’s look at another snippet to show a bit more detail about how this works:
Sep 29 20:50:45 localhost sudo: donnie : TTY=pts/0 ; PWD=/home/donnie ; USER=root ; COMMAND=/bin/less /var/log/secure Sep 29 20:55:30 localhost sudo: donnie : TTY=pts/0 ; PWD=/home/donnie ; USER=root ; COMMAND=/sbin/fdisk -l Sep 29 20:55:40 localhost sudo: donnie : TTY=pts/0 ; PWD=/home/donnie ; USER=root ; COMMAND=/bin/yum upgrade Sep 29 20:59:35 localhost sudo: donnie : TTY=tty1 ; PWD=/home/donnie ; USER=root ; COMMAND=/bin/systemctl status sshd Sep 29 21:01:11 localhost sudo: donnie : TTY=tty1 ; PWD=/home/donnie ; USER=root ; COMMAND=/bin/less /var/log/secure
This time, I used my sudo privilege to open a log file, to view my hard drive configuration, to perform a system update, to check the status of the Secure Shell daemon, and to once again view a log file. So, if you were the security administrator at my company, you’d be able to see whether or not I’m abusing my sudo power.
Now, you’re asking, “What’s to prevent a person from just doing a sudo su - to prevent his or her misdeeds from being detected?” That’s easy. Just don’t give people the power to go to the root command prompt.
Setting up sudo privileges for full administrative users
Before we look at how to limit what users can do, let’s first look at how to allow a user to do everything, including logging in to the root command prompt. There are a couple of methods for doing that.
Adding users to a predefined admin group
The first method, which is the simplest, is to add users to a predefined administrators group and then, if it hasn’t already been done, to configure the sudo policy to allow that group to do its job. It’s simple enough to do except that different Linux distribution families use different admin groups.
On Unix, BSD, and most Linux systems, you would add users to the wheel group. (Members of the Red Hat family, including CentOS, fall into this category.) When I do the groups command on either of my CentOS machines, I get this:
[satish@localhost ~]$ groups satish wheel [satish@localhost ~]$
This shows that I’m a member of the wheel group. By doing sudo visudo, I’ll open the sudo policy file. Scrolling down, we’ll see the line that gives the wheel group its awesome power:
## Allows people in group wheel to run all commands %wheel ALL=(ALL) ALL
The percent sign indicates that we’re working with a group. The three appearances of ALL means that members of that group can perform any command, as any user, on any machine in the network on which this policy is deployed. The only slight catch is that group members will be prompted to enter their own normal user account passwords in order to perform a sudo task. Scroll down a bit more and you’ll see the following:
## Same thing without a password # %wheel ALL=(ALL) NOPASSWD: ALL
If we were to comment out the %wheel line in the former snippet and remove the comment symbol from in front of the %wheel line in this snippet, then members of the wheel group would be able to perform all of their sudo tasks without ever having to enter any password. That’s something that I really don’t recommend, even for home use. In a business setting, allowing people to have password-less sudo privileges is a definite no-no.
To add an existing user to the wheel group, use usermod with the -G option. You might also want to use the -a option, in order to prevent removing the user from other groups to which he or she belongs. For our example, let’s add Maggie:
$ sudo usermod -a -G wheel maggie
You can also add a user account to the wheel group as you create it. Let’s do that now for Frank:
$ sudo useradd -G wheel frank
Note that, with my usage of useradd, I’m assuming that we’re working with a member of the Red Hat family, which comes with predefined default settings to create user accounts. For non-Red Hat-type distributions that use the wheel group, you’d need to either reconfigure the default settings or use extra option switches in order to create the user’s home directory and to assign the correct shell. Your command then would look something like this:
sudo useradd -G wheel -m -d /home/frank -s /bin/bash frank
For members of the Debian family, including Ubuntu, the procedure is the same, except that you would use the sudo group instead of the wheel group.
Creating an entry in the sudo policy file
Okay, adding users to either the wheel group or the sudo group works great if you’re either just working with a single machine or if you’re deploying a sudo policy across a network that uses just one of these two admin groups. But what if you want to deploy a sudo policy across a network with a mixed group of both Red Hat and Ubuntu machines? Or what if you don’t want to go around to each machine to add users to an admin group? Then, just create an entry in the sudo policy file. You can either create an entry for an individual user or create a user alias. If you do sudo visudo on your CentOS virtual machine, you’ll see a commented-out example of a user alias:
# User_Alias ADMINS = jsmith, mikem
You can uncomment this line and add your own set of usernames, or you can just add a line with your own user alias. To give members of the user alias full sudo power, add another line that would look like this:
ADMINS ALL=(ALL) ALL
It’s also possible to add a visudo entry for just a single user, and you might need to do that under very special circumstances. Here’s an example:
frank ALL=(ALL) ALL
But for ease of management, it’s best to go with either a user group or a user alias.
The sudo policy file is the /etc/sudoers file. I always hesitate to tell students that because, every once in a while, I have a student try to edit it in a regular text editor. That doesn’t work though, so please don’t try it. Always edit sudoers with the sudo visudo command.