<h1>Title: Configuring superuser access on RHEL</h1>
<p>
On Linux, everything starts at "root".
The hard drive itself has a root partition (<code>/</code>), and the default initial user is, at least traditionally, <code>root</code> (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 <code>sudo</code> 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.
</p>
<h2>Locking root at install</h2>
<p>
An attacker with enough knowledge to attempt a break-in also has knowledge that historically every Unix and Linux system had a user called <code>root</code>.
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.
</p>
<p>
During installation, you have the option to lock the root accont.
</p>
<p><b>INSERT rhel-install-root-user-lock.jpg</b></p>
<p>
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.
</p>
<p><b>INSERT rhel-install-wheel-user.jpg</b></p>
<p>
Making the user an admin adds that user to the special <code>wheel</code> group.
By default, members of <code>wheel</code> are able to run any command with <code>sudo</code> with, essentially, root privilege.
It seems nearly the same as using <code>su</code> to switch to the superuser account, but there are <a href="
https://opensource.com/article/22/5/use-sudo-linux" target="_blank">safeguards and advantages</a> to <code>sudo</code>.
</p>
<h2>Disable root</h2>
<p>
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 <a href="
https://www.redhat.com/sysadmin/sudo" target="_blank">add your user to the sudoers file</a> and then use <code>sudo</code> to disable root.
</p>
<p>
To disable root, set the root shell to <code>/sbin/nologin</code>:
</p>
<pre><code>
$ sudo sed -i 's_root:/bin/bash_root:/sbin/nologin_' /etc/passwd
</code></pre>
<p>
Test your change by attempting to switch to the superuser account with <code>su</code>:
</p>
<pre><code>$ sudo su -
[sudo] password for tux:
This account is currently not available.
</code></pre>
<h2>Managing administration</h2>
<p>
The <code>su</code> 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.
</p>
<p>
Suppose you want to grant a user permission to run a specific application, such as the <code>groupadd</code> command, that usually requires administrative permissions.
You don't want to give this user permission to do <em>any</em> administrative task.
You just want to allow the creation of new groups.
</p>
<p>
To grant selective privileges to a single command or a group of commands, edit <code>/etc/sudoers</code> with the <code>visudo</code> command.
The <code>visudo</code> command assumes you want to edit text with <code>vi</code> but does allow you to override that default by setting the variable <code>EDITOR</code>:
</p>
<pre><code>$ sudo EDITOR=nano visudo</code></pre>
<p>
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 <code>shadowman</code> to run the <code>groupadd</code> command:
</p>
<pre><code>
## 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</code></pre>
<p>
Test it out by switching to that user's account and running the command:
</p>
<pre><code>
$ 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.</code></pre>
<h2>Sudo aliases</h2>
<p>
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 <code>useradd</code>, <code>groupadd</code>, and <code>usermod</code>, and a software group that could use commands like <code>dnf</code> and <code>rpm</code>.
The sudoers file provides example syntax, but here's an example of allowing all users in the UNIX group <code>softadmins</code> to run all commands in the sudoer alias <code>SOFTWARE</code>:
</p>
<pre><code>
## Installation and management of software
Cmnd_Alias SOFTWARE = /usr/bin/dnf, /usr/bin/rpm
softadmins ALL=SOFTWARE
</code></pre>
<h2>Protect your admin privileges</h2>
<p>
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 <code>sudo</code> command and a well-tended sudoers file to manage who can manage your computers.
</p>
