RED HAT ENTERPRISE LINUX

Configure
Privileged Access

Configure privileged access

CIS126RH | RHEL System Administration 1
Mesa Community College

Privileged access control is a foundational security requirement — regular users need to run administrative commands without knowing the root password and without switching to a fully privileged root shell. On RHEL 9, sudo (superuser do) is the standard mechanism. It grants selected users and groups the ability to run specific commands as root (or as other users), logs every privileged action, and is configured through the /etc/sudoers file and drop-in files in /etc/sudoers.d/. sudo configuration is tested on the RHCSA exam.

Learning Objectives

1. Explain how sudo works and why it is preferred over direct root access — Describe the authentication, logging, and delegation model that makes sudo the enterprise standard for privileged access
2. Grant full sudo access using the wheel group — Use usermod -aG wheel to add users to the pre-configured wheel group and verify sudo access
3. Write custom sudoers rules — Use visudo to create precise rules granting specific users or groups access to specific commands with or without a password
4. Use drop-in files and test sudo configuration — Create rules in /etc/sudoers.d/ and use sudo -l to verify what a user is allowed to run

Why sudo? The Privileged Access Model

Logging in as root or using su - to switch to root has serious disadvantages that sudo is designed to address.

The wheel Group: Full sudo Access

On RHEL 9, the wheel group is pre-configured in /etc/sudoers to allow members to run any command as root. This is the simplest way to grant full administrative access.

# The wheel group rule in /etc/sudoers (pre-configured on RHEL 9)
%wheel  ALL=(ALL)  ALL
# % = group; ALL = any host; (ALL) = as any user; ALL = any command

# Grant full sudo access: add a user to the wheel group
$ sudo usermod -aG wheel alice

# Verify alice is in wheel
$ id alice
uid=1001(alice) gid=1001(alice) groups=1001(alice),10(wheel)

# Test: alice can now run sudo commands
$ sudo -u alice sudo whoami
root

# Or switch to alice and test directly
$ su - alice
$ sudo whoami
[sudo] password for alice:
root

/etc/sudoers: The Configuration File

The /etc/sudoers file defines all sudo rules. It must always be edited with visudo — never directly with a text editor.

# Open /etc/sudoers safely with visudo
$ sudo visudo

# Key sections in the default /etc/sudoers
## Allows root to run any commands anywhere
root    ALL=(ALL)       ALL

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

## Same thing without password requirement
# %wheel  ALL=(ALL)   NOPASSWD: ALL

## Read drop-in files from /etc/sudoers.d/
#includedir /etc/sudoers.d

The sudoers Rule Format

Every sudoers rule follows a precise syntax. Understanding each field allows precise control over what is permitted.

# Format: WHO  WHERE=(AS_WHOM)  WHAT
#
alice       ALL=(ALL)       ALL
# alice can run ANY command as ANY user on ANY host
#
%developers ALL=(ALL)       /usr/bin/systemctl
# developers group can run systemctl as root on any host
#
bob         ALL=(root)      NOPASSWD: /usr/bin/dnf
# bob can run dnf as root without a password
#
carol       servera=(root)  /sbin/reboot, /sbin/halt
# carol can reboot or halt only on servera

Writing Custom sudoers Rules

Custom rules grant a user or group access to specific commands — more secure than granting full sudo access.

# Open visudo to add custom rules
$ sudo visudo

# Allow alice to run systemctl commands as root
alice  ALL=(root)  /usr/bin/systemctl

# Allow the operators group to restart specific services only
%operators  ALL=(root)  /usr/bin/systemctl restart httpd, /usr/bin/systemctl restart sshd

# Allow bob to run dnf without entering a password
bob  ALL=(root)  NOPASSWD: /usr/bin/dnf

# Allow carol to run ALL commands without a password (less secure)
carol  ALL=(ALL)  NOPASSWD: ALL

# Verify: list what a user can run with sudo
$ sudo -l -U alice
Matching Defaults entries for alice on servera:
    ...
User alice may run the following commands on servera:
    (root) /usr/bin/systemctl

Drop-in Files: /etc/sudoers.d/

The preferred way to add custom rules is in separate files under /etc/sudoers.d/ — keeping the main /etc/sudoers clean and making rules easy to manage and remove.

# Create a drop-in rule file for alice
$ sudo visudo -f /etc/sudoers.d/alice
# Add inside the file:
alice  ALL=(root)  /usr/bin/systemctl

# Create a rule file for the devops group
$ sudo visudo -f /etc/sudoers.d/devops
%devops  ALL=(root)  NOPASSWD: /usr/bin/dnf, /usr/bin/systemctl

# List all drop-in files
$ ls /etc/sudoers.d/
alice  devops  README

# Verify with visudo --check (syntax check all files)
$ sudo visudo --check
/etc/sudoers: parsed OK
/etc/sudoers.d/alice: parsed OK
/etc/sudoers.d/devops: parsed OK

NOPASSWD and Other sudoers Tags

Tags modify how sudo applies a rule. They appear before the command list in the WHAT field.

# NOPASSWD: run commands without being prompted for a password
alice  ALL=(root)  NOPASSWD: /usr/bin/systemctl restart httpd

# PASSWD: override a NOPASSWD inherited from a group (require password)
bob    ALL=(root)  PASSWD: /usr/bin/dnf, NOPASSWD: /usr/bin/systemctl

# NOEXEC: prevent sudo from running subshells or other programs
carol  ALL=(root)  NOEXEC: /usr/bin/less

# ! (negation): explicitly deny a specific command
%developers  ALL=(root)  ALL, !/bin/bash, !/bin/sh
# Above: allow all commands EXCEPT bash and sh (shell access blocked)
# Note: negation is not foolproof — avoid relying on it for security

Testing sudo Configuration

# List all commands the current user can run with sudo
$ sudo -l
Matching Defaults entries for alice on servera:
    env_reset, mail_badpass, ...

User alice may run the following commands on servera:
    (root) /usr/bin/systemctl

# List commands a specific user can run (run as root)
$ sudo -l -U bob
User bob may run the following commands on servera:
    (root) NOPASSWD: /usr/bin/dnf

# Test running a command as alice without switching to her
$ sudo -u alice id
uid=1001(alice) gid=1001(alice) groups=1001(alice)

# Check the sudo log for recent activity
$ sudo grep sudo /var/log/secure | tail -10
May 25 10:00:01 servera sudo: alice : TTY=pts/0 ; PWD=/home/alice ;
    USER=root ; COMMAND=/usr/bin/systemctl restart httpd

Aliases: Organising Complex Rules

Aliases allow groups of users, hosts, or commands to be named and reused — making large sudoers configurations easier to manage.

# In /etc/sudoers or a drop-in file:

# User_Alias — named group of users
User_Alias  WEBADMINS = alice, bob, carol

# Cmnd_Alias — named group of commands
Cmnd_Alias  WEBSERVICES = /usr/bin/systemctl restart httpd, \
                           /usr/bin/systemctl reload httpd, \
                           /usr/bin/systemctl status httpd

# Runas_Alias — named group of users to run as
Runas_Alias WEBRUNNERS = root, apache

# Use aliases in rules
WEBADMINS  ALL=(WEBRUNNERS)  WEBSERVICES
# All WEBADMINS can run WEBSERVICES as root or apache

# This is equivalent to listing all combinations individually
# but much more maintainable at scale

sudo Defaults and Configuration

The Defaults section in /etc/sudoers controls system-wide sudo behaviour.

# Common Defaults entries in /etc/sudoers
Defaults    env_reset           # reset environment when running sudo
Defaults    mail_badpass        # email root on failed sudo attempts
Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin
Defaults    timestamp_timeout=5 # credential cache: 5 minutes (default)

# Increase the credential cache timeout
Defaults    timestamp_timeout=15

# Require password every time (no caching)
Defaults    timestamp_timeout=0

# Enable sudo logging to a file
Defaults    logfile=/var/log/sudo.log

# Apply a Default to a specific user only
Defaults:alice  timestamp_timeout=30

# Run sudo without a TTY (useful for scripts)
Defaults    !requiretty

Switching to Root: su and sudo -i

Sometimes full root shell access is needed. Two methods exist — both require appropriate privileges, but only one requires knowing the root password.

# su - : switch to root with full environment (requires root password)
$ su -
Password:
[root@servera ~]#

# sudo -i : open a root login shell (requires sudo ALL access)
$ sudo -i
[sudo] password for alice:
[root@servera ~]#

# sudo -s : open a root shell without login environment
$ sudo -s

# sudo su - : another common pattern (uses sudo then su)
$ sudo su -

# Run a single command as root
$ sudo systemctl restart httpd

# Switch to another user (not root)
$ sudo -u bob whoami
bob

Privileged Access Quick Reference

Common Mistakes

Complete Configuration Workflow

Two exam scenarios: (A) grant full admin access; (B) grant limited command access.

Scenario A: Full sudo access for alice

$ sudo usermod -aG wheel alice
$ sudo -l -U alice   # verify
    (ALL) ALL

Scenario B: bob can restart httpd without a password

$ sudo visudo -f /etc/sudoers.d/bob
# Add this line:
bob  ALL=(root)  NOPASSWD: /usr/bin/systemctl restart httpd

# Verify syntax
$ sudo visudo --check

# Verify bob's permissions
$ sudo -l -U bob
    (root) NOPASSWD: /usr/bin/systemctl restart httpd

# Test as bob
$ su - bob -c "sudo systemctl restart httpd"
      ← no password prompt, command succeeds

Knowledge Check

Answer these before moving to the next slide.

1. Write the command to grant user carol full sudo access on RHEL 9. Why does this work without editing /etc/sudoers?
2. Write the sudoers rule to allow user dave to run /usr/bin/dnf as root without being prompted for a password.
3. You need to add this rule for dave using a drop-in file. Write the full command to create it safely, and what must the filename NOT contain?
4. Write the command to verify what sudo commands dave is allowed to run. What command would an administrator use to check dave's permissions without switching to his account?
5. Why should you always use visudo instead of a plain text editor to modify sudoers files?
6. A sudoers rule contains !/bin/bash. What does this mean, and why is it not a reliable security boundary?

Knowledge Check — Answers

1. sudo usermod -aG wheel carol. This works without editing sudoers because RHEL 9 ships with the pre-configured rule %wheel ALL=(ALL) ALL in /etc/sudoers — any member of the wheel group automatically has full sudo access.
2. dave ALL=(root) NOPASSWD: /usr/bin/dnf
   This goes in /etc/sudoers (via visudo) or in a drop-in file.
3. sudo visudo -f /etc/sudoers.d/dave
   The filename must NOT contain a dot (.) — files with dots in the name are silently ignored by the #includedir directive. So dave is valid; dave.conf is not.
4. As dave: sudo -l
   As root checking dave: sudo -l -U dave
   Both show the matching sudoers rules and which commands dave is permitted to run.
5. visudo validates the file's syntax before saving. A syntax error in /etc/sudoers disables all sudo access on the system. If sudo is the only way to gain root access (root password not set), a broken sudoers file causes a complete administrative lockout. visudo prevents this by refusing to save a file with syntax errors.
6. !/bin/bash explicitly denies running /bin/bash via sudo. It is not reliable because there are many other ways to obtain a shell — through editors (vim's :!bash), pagers (less's !bash), or other programs. The correct approach is to allow only specific, audited commands (allowlist) rather than trying to deny known shells (denylist).

Key Takeaways

1. Grant full sudo access by adding to the wheel group. sudo usermod -aG wheel USERNAME — the pre-configured %wheel ALL=(ALL) ALL rule in /etc/sudoers does the rest. The user must log out and back in for the new membership to take effect.
2. Always use visudo — never a plain text editor. sudo visudo for the main file; sudo visudo -f /etc/sudoers.d/NAME for drop-in files. Syntax errors disable all sudo access. Drop-in filenames must not contain dots.
3. Rule format: WHO ALL=(root) [NOPASSWD:] /full/path/command. Use %GROUPNAME for groups. Always use absolute command paths. NOPASSWD: removes the password prompt for automation. ALL in the WHAT position grants full sudo access.
4. Verify with sudo -l -U USERNAME and test by switching users. sudo --check validates syntax. sudo -l -U USER shows what a user is permitted to run. Every sudo action is logged in /var/log/secure with the real username.

Graded Lab

• Create user labadmin. Add them to the wheel group with usermod -aG wheel. Verify with id labadmin. Switch to labadmin and confirm they can run sudo whoami and get the response root.
• Create user labops. Use visudo -f /etc/sudoers.d/labops to create a drop-in rule allowing labops to run /usr/bin/systemctl as root without a password. Run visudo --check to validate syntax.
• Verify labops's permissions with sudo -l -U labops. Switch to labops and run sudo systemctl status sshd — confirm it succeeds without a password prompt. Attempt sudo dnf list — confirm it is denied.
• Create a drop-in file /etc/sudoers.d/labops.conf (note the dot). Confirm with sudo -l -U labops that the rules in the dotted file are NOT loaded. Delete the dotted file and recreate it as labops-extra — confirm it IS loaded.
• Check /var/log/secure for the sudo audit entries generated during the lab. Identify the log entries for labadmin's sudo whoami and labops's systemctl command. Note the username, timestamp, and command recorded.
• Remove labops from the sudoers drop-in by deleting /etc/sudoers.d/labops. Verify with sudo -l -U labops that they no longer have any sudo permissions. Attempt a sudo command as labops and confirm it is denied.

Next: Getting Help from Local Documentation