Title: Configuring superuser access on RHEL

On Linux, everything starts at "root". The hard drive itself has a root partition (/), and the default initial user is, at least traditionally, root (often referred to as the "superuser"). Historically, it was the root account that you used to log in, create secondary "normal" users, and then mostly forget about. These days, though, the root user is redundant to requirements. The Anaconda installer can create an initial user for you, and then you can perform "superuser" tasks with the sudo command. It's important for a computer's admin to understand how to configure superuser access so that it's well out of the way of people who don't need it, and available to those who require it.

Locking root at install

An attacker with enough knowledge to attempt a break-in also has knowledge that historically every Unix and Linux system had a user called root. That's one less guess an attacker has to make when attempting unauthorized entry into a system. Locking down the root account is a significant foil to uninvited guests.

During installation, you have the option to lock the root accont.

INSERT rhel-install-root-user-lock.jpg

Locking the root account prevents you from logging in as root user. If you do that, grant the user you create administrative privileges during user creation.

INSERT rhel-install-wheel-user.jpg

Making the user an admin adds that user to the special wheel group. By default, members of wheel are able to run any command with sudo with, essentially, root privilege. It seems nearly the same as using su to switch to the superuser account, but there are safeguards and advantages to sudo.

Disable root

If you didn't lock the root account during install, or if you're unsure, then you can disable the root account later, as long as you have administrative privileges. If you don't, then use the root account to add your user to the sudoers file and then use sudo to disable root.

To disable root, set the root shell to /sbin/nologin:


$ sudo sed -i 's_root:/bin/bash_root:/sbin/nologin_' /etc/passwd

Test your change by attempting to switch to the superuser account with su:

$ sudo su -
[sudo] password for tux: 
This account is currently not available.

Managing administration

The su command uses an all-or-nothing model. If you have the password root, you get all the power. If you don't have the password, you have no admin power. The problem with this model is that a sysadmin has to choose between handing over the master key to the system, or withholding the key and all control of the system. That's not always what you want. Sometimes you want to delegate.

Suppose you want to grant a user permission to run a specific application, such as the groupadd command, that usually requires administrative permissions. You don't want to give this user permission to do any administrative task. You just want to allow the creation of new groups.

To grant selective privileges to a single command or a group of commands, edit /etc/sudoers with the visudo command. The visudo command assumes you want to edit text with vi but does allow you to override that default by setting the variable EDITOR:

$ sudo EDITOR=nano visudo

Find the section of the sudoers file defining command permissions, and add the user and command you want to allow. For instance, to permit the user shadowman to run the groupadd command:


## Next comes the main part: which users can run what software on 
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
## 	user	MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere 
# root	  ALL=(ALL) 	ALL
shadowman ALL=/sbin/groupadd

Test it out by switching to that user's account and running the command:


$ su - shadowman
Password: 
$ sudo groupadd qa
[sudo] password for shadowman: 
$ sudo ls
Sorry, user bogan is not allowed to execute '/bin/ls' 
as root on darkstar.sysadmin.local.

Sudo aliases

You can create aliases in the sudoers file to group hosts, commands, and users together. You could have, for instance, an admin group that could use commands such as useradd, groupadd, and usermod, and a software group that could use commands like dnf and rpm. The sudoers file provides example syntax, but here's an example of allowing all users in the UNIX group softadmins to run all commands in the sudoer alias SOFTWARE:


## Installation and management of software
Cmnd_Alias SOFTWARE = /usr/bin/dnf, /usr/bin/rpm
softadmins ALL=SOFTWARE

Protect your admin privileges

Everything from mission-critical machines to computers with customer data, and even your own humble personal laptop, are too important to casually lend the keys out to anyone who needs an escalation of privilege. Disable the root account to avoid broad permission escalation, and use the sudo command and a well-tended sudoers file to manage who can manage your computers.