LFCS 41 🐧 Privilege Escalation — sudo - KandZ

⏱️ Estimated read: 11 min | |

The sudo command is the standard mechanism for delegated privilege escalation on Linux. Its purpose is to allow trusted users to execute specific commands as root—or as another user—without sharing the root password or opening a persistent root shell . For the LFCS exam, sudo falls under both “Configure sudo access and command aliases” in the Users and Groups domain and “Restrict privilege escalation via sudo” in the Security domain .

The core of sudo configuration is the /etc/sudoers file and its drop-in directory /etc/sudoers.d/. Every rule follows the format WHO WHERE=(AS_WHOM) WHAT. A malformed entry can lock you out of administrative access entirely, which is why the file must never be edited with a normal text editor. The visudo utility validates syntax before saving, and visudo -f does the same for individual drop-in files . Understanding how to grant, restrict, and audit sudo access is not just exam material—it is the difference between a system that can be administered and one that must be reinstalled.

Key point: sudo executes a command as another user (root by default) according to rules in /etc/sudoers and /etc/sudoers.d/; the standard entry format is user ALL=(ALL:ALL) ALL, and visudo must be used for all edits because a syntax error can revoke all sudo access.

Why sudo exists

The shared root password problem. Before sudo, granting administrative access meant sharing the root password. Every administrator knew the password, every action was logged as root with no attribution, and revoking access required changing the password for everyone. sudo solves this by allowing users to authenticate with their own password while executing commands as root, with each invocation logged under the invoking user’s identity .

The least privilege problem. Not every administrative task requires full root access. A database administrator needs to restart PostgreSQL, not modify kernel parameters. A web developer needs to reload Nginx, not create users. sudo allows fine-grained delegation: specific users or groups can run specific commands, and nothing else. The syntax supports command aliases, host restrictions, and run-as restrictions to enforce this .

The audit problem. When multiple administrators share the root password, the logs show only root. There is no way to know who executed a destructive command. With sudo, every invocation is logged with the invoking username, the command, and the timestamp. This audit trail is essential for forensic analysis and compliance .

The session problem. Running as root indefinitely is dangerous. A mistyped command can destroy the system. sudo is deliberately temporary: the privilege elevation applies to a single command, and the credential cache expires after a short period (typically 15 minutes). The user returns to normal privileges immediately after the command completes .

The configuration fragility problem. The /etc/sudoers file is parsed by a strict grammar. A misplaced comma or an invalid alias can cause sudo to refuse all requests. This is why visudo exists: it parses the file, reports errors, and refuses to save invalid syntax. It also performs file locking to prevent concurrent edits . Without visudo, a single typo can require single-user mode recovery.

a. Granting sudo access via groups

The simplest and most maintainable way to grant sudo access is group membership. The group name differs by distribution family: Debian-based systems (Ubuntu, Mint) use the sudo group; RHEL-based systems (RHEL, CentOS, Rocky, AlmaLinux) use the wheel group .

To add a user to the appropriate group:

# Debian/Ubuntu
sudo usermod -aG sudo username

# RHEL/CentOS/Rocky
sudo usermod -aG wheel username

The -aG flags mean “append to group,” which is critical—omitting -a removes the user from all other supplementary groups . The group membership takes effect on the next login. Existing sessions do not reload group memberships, so the user must log out and back in (or start a new SSH session) before sudo works .

The group-based approach works because the default /etc/sudoers file contains commented-out lines that grant full privileges to these groups:

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

Uncommenting the line activates the rule. On most systems, the sudo group has an equivalent entry . This is why adding a user to the group is sufficient—the rule is already in place, just commented out.

You can verify group membership with groups username or getent group sudo .

b. Fine-grained sudoers rules

When group-based full access is too broad, you write explicit rules. The syntax is:

WHO  WHERE=(AS_WHOM)  WHAT

WHO: the user or %group the rule applies to
WHERE: the hostname (usually ALL)
AS_WHOM: the user/group the command runs as, in parentheses (usually ALL or root)
WHAT: the command(s) allowed, with absolute paths

A rule granting full sudo access to a single user:

alice  ALL=(ALL:ALL) ALL

A rule restricting a user to specific commands:

bob  ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx

A rule allowing a group to manage a service:

%webadmins  ALL=(root) /usr/bin/systemctl start httpd, /usr/bin/systemctl stop httpd, /usr/bin/systemctl restart httpd

Command aliases reduce repetition and improve readability:

Cmnd_Alias SERVICES = /usr/bin/systemctl start *, /usr/bin/systemctl stop *, /usr/bin/systemctl restart *, /usr/bin/systemctl status *
Cmnd_Alias LOGS = /usr/bin/journalctl --no-pager -u *, /usr/bin/tail -f /var/log/*

%ops  ALL=(root) SERVICES, LOGS

The NOPASSWD: tag disables the password prompt for specific commands. It is useful for automation but reduces auditability:

deploy  ALL=(root) NOPASSWD: /opt/deploy/run-deploy.sh

You can also explicitly deny commands with !:

%developers  ALL=(root) ALL, !/usr/sbin/useradd, !/usr/sbin/userdel, !/usr/bin/passwd

This grants full access except for user management commands .

All edits must go through visudo. For the main file, run sudo visudo. For a drop-in file, run sudo visudo -f /etc/sudoers.d/filename .

c. The `/etc/sudoers.d/` drop-in directory

The main /etc/sudoers file should not be the place for custom rules. It is fragile, and OS upgrades may overwrite it. The standard practice is to place custom configurations in /etc/sudoers.d/, which is included by the main file via the #includedir directive .

Files in /etc/sudoers.d/ must follow strict permissions: owned by root:root and mode 0440 (read-only for root, no access for anyone else). The directory is parsed in lexicographical order, so numeric prefixes like 10-admins and 20-developers control precedence .

A typical workflow:

sudo visudo -f /etc/sudoers.d/webadmins

This opens a new file in visudo, validates syntax on save, and sets the correct permissions automatically. The content follows the same syntax as the main file:

%webadmins  ALL=(root) /usr/bin/systemctl restart httpd

The advantages of drop-in files are modularity and safety. A syntax error in one file does not necessarily break the entire sudo configuration (though it may still cause problems depending on the error), and you can remove a file to revoke a set of permissions without touching the main configuration .

Complete Example Session

The following session demonstrates granting sudo access via group membership, creating a fine-grained rule in a drop-in file, and verifying the result.

# ============================================
# PART 1: CHECK CURRENT SUDO ACCESS
# ============================================
# As a user without sudo, attempt a privileged command
sudo whoami
# Output: user is not in the sudoers file. This incident will be reported.

# ============================================
# PART 2: ADD USER TO SUDO GROUP (Debian/Ubuntu)
# ============================================
# As root or an existing sudo user
sudo usermod -aG sudo alice

# ============================================
# PART 3: VERIFY GROUP MEMBERSHIP
# ============================================
groups alice
# Output: alice : alice sudo

# ============================================
# PART 4: NEW LOGIN REQUIRED
# ============================================
# Group changes do not apply to existing sessions
# alice must log out and log back in
su - alice
# Now sudo works
sudo whoami
# Output: root

# ============================================
# PART 5: CREATE A FINE-GRAINED RULE
# ============================================
sudo visudo -f /etc/sudoers.d/webadmins

# Content of the file:
# %webadmins ALL=(root) /usr/bin/systemctl restart nginx
# %webadmins ALL=(root) /usr/bin/systemctl status nginx

# ============================================
# PART 6: ADD USER TO CUSTOM GROUP
# ============================================
sudo groupadd webadmins
sudo usermod -aG webadmins bob

# ============================================
# PART 7: TEST THE RULE
# ============================================
# As bob (after re-login)
sudo systemctl restart nginx
# Allowed: matches the rule

sudo systemctl stop nginx
# Denied: command not in the rule
# Output: Sorry, user bob is not allowed to execute '/usr/bin/systemctl stop nginx' as root

# ============================================
# PART 8: NOPASSWD FOR AUTOMATION
# ============================================
sudo visudo -f /etc/sudoers.d/deploy

# Content:
# deploy ALL=(root) NOPASSWD: /opt/deploy/run.sh

# ============================================
# PART 9: CHECK SUDO PRIVILEGES
# ============================================
sudo -l
# Lists the commands the current user may run

# ============================================
# PART 10: CLEANUP AND VERIFICATION
# ============================================
sudo rm /etc/sudoers.d/webadmins
sudo rm /etc/sudoers.d/deploy
# Rules removed, access revoked

The ten parts cover the initial failure state, group-based access, verification, the login requirement, fine-grained rule creation, custom group setup, testing allowed and denied commands, NOPASSWD for automation, privilege listing, and cleanup. What the session demonstrates is that sudo access is layered: group membership provides a baseline, and explicit rules in drop-in files provide granular control.

Quick Reference

Granting sudo Access

Distribution	Group	Command
Debian/Ubuntu	`sudo`	`usermod -aG sudo username`
RHEL/CentOS	`wheel`	`usermod -aG wheel username`

Sudoers Syntax

Component	Meaning	Example
WHO	User or `%group`	`alice`, `%wheel`
WHERE	Hostname	`ALL`
AS_WHOM	Run-as user/group	`(ALL:ALL)`, `(root)`
WHAT	Allowed commands	`/usr/bin/systemctl restart nginx`

Common Rules

Rule	Effect
`alice ALL=(ALL:ALL) ALL`	Full sudo for alice
`%wheel ALL=(ALL) ALL`	Full sudo for wheel group
`bob ALL=(root) /bin/ls, /bin/stat`	bob can run only ls and stat as root
`deploy ALL=(root) NOPASSWD: /opt/run.sh`	deploy runs run.sh without password

Sudoers Files

File/Directory	Purpose
`/etc/sudoers`	Main configuration
`/etc/sudoers.d/`	Drop-in directory
`visudo`	Syntax-checked editor
`visudo -f file`	Edit a drop-in file

Best Practices

✅ Do This:

visudo -f /etc/sudoers.d/webadmins                         # ✅ syntax-checked edit
usermod -aG wheel alice                                    # ✅ append, not replace
%webadmins ALL=(root) /usr/bin/systemctl restart nginx     # ✅ least privilege
sudo -l                                                    # ✅ verify privileges

❌ Don’t Do This:

nano /etc/sudoers                                          # ❌ no syntax check
usermod -G wheel alice                                     # ❌ removes other groups
alice ALL=(ALL) ALL                                        # ❌ overly broad if not needed
chmod 0666 /etc/sudoers.d/rule                             # ❌ insecure permissions

Common Pitfalls

Pitfall	Why It Happens	Fix
“User is not in sudoers file”	No group membership or rule	Add to `sudo` or `wheel` group
Group added but sudo still fails	Session not reloaded	Log out and back in
`usermod -G` removed other groups	Missing `-a` flag	Use `-aG`
Syntax error breaks sudo	Edited without `visudo`	Always use `visudo`
Drop-in file ignored	Wrong permissions	`chmod 0440`, `chown root:root`
Command not allowed despite rule	Path mismatch	Use absolute paths in rules

Real-World Examples

1. Add user to sudo group (Debian)

usermod -aG sudo alice

2. Add user to wheel group (RHEL)

usermod -aG wheel bob

3. Full sudo rule

alice ALL=(ALL:ALL) ALL

4. Restrict to service management

%webadmins ALL=(root) /usr/bin/systemctl restart nginx

5. Passwordless deploy script

deploy ALL=(root) NOPASSWD: /opt/deploy/run.sh

6. Command alias

Cmnd_Alias SERVICES = /usr/bin/systemctl start *, /usr/bin/systemctl stop *

7. Deny specific commands

%developers ALL=(root) ALL, !/usr/sbin/useradd

8. Edit drop-in file safely

visudo -f /etc/sudoers.d/10-admins

9. List privileges

sudo -l

10. Run as another user

sudo -u alice whoami

Visual

Sudo Decision Flow

┌──────────────────────────────────────────────┐
│  user runs: sudo command                     │
│         │                                    │
│         ▼                                    │
│  Check /etc/sudoers and /etc/sudoers.d/      │
│         │                                    │
│    ┌────┴────┐                               │
│    │         │                               │
│  rule      no rule                           │
│  found     found                             │
│    │         │                               │
│    ▼         ▼                               │
│  Allowed?  Deny: "not in sudoers file"       │
│    │                                         │
│  ┌─┴─┐                                       │
│  │   │                                       │
│ Yes  No                                     │
│  │   │                                       │
│  ▼   ▼                                       │
│ Run  Deny: "not allowed to execute"          │
│ as                                           │
│ root                                         │
└──────────────────────────────────────────────┘

Group-Based Access

┌──────────────────────────────────────────────┐
│  DEFAULT /etc/sudoers                        │
│                                              │
│  # %wheel ALL=(ALL) ALL   ← commented        │
│  # %sudo   ALL=(ALL:ALL) ALL  ← commented    │
│                                              │
│  ADD USER TO GROUP                           │
│  usermod -aG wheel alice                     │
│         │                                    │
│         ▼                                    │
│  alice is now in wheel group                 │
│         │                                    │
│         ▼                                    │
│  Rule applies (if uncommented)               │
│         │                                    │
│         ▼                                    │
│  alice can run sudo commands                 │
└──────────────────────────────────────────────┘

Sudoers Rule Anatomy

┌──────────────────────────────────────────────┐
│  %webadmins  ALL=(root)  /usr/bin/systemctl  │
│  ──────────  ─── ──────  ─────────────────── │
│  WHO         WHERE AS_WHOM  WHAT             │
│                                              │
│  WHO:     %webadmins = members of group      │
│  WHERE:   ALL = any host                     │
│  AS_WHOM: (root) = run as root               │
│  WHAT:    /usr/bin/systemctl = exact path    │
│                                              │
│  Result: webadmins can run systemctl as root │
│  (not stop, unless specified)                │
└──────────────────────────────────────────────┘

Drop-in Directory

┌──────────────────────────────────────────────┐
│  /etc/sudoers                                │
│  #includedir /etc/sudoers.d                  │
│         │                                    │
│         ▼                                    │
│  /etc/sudoers.d/                             │
│  ├── 10-admins      (parsed first)           │
│  ├── 20-developers  (parsed second)          │
│  └── 30-deploy      (parsed third)           │
│                                              │
│  Each file: root:root, mode 0440             │
│  Edit with: visudo -f /etc/sudoers.d/file    │
└──────────────────────────────────────────────┘

Summary

Item	Value
Sudo purpose	Delegated privilege escalation
Main config	`/etc/sudoers`
Drop-in dir	`/etc/sudoers.d/`
Safe editor	`visudo`
Debian group	`sudo`
RHEL group	`wheel`
Add to group	`usermod -aG group user`
Rule format	`WHO WHERE=(AS_WHOM) WHAT`
Full access	`user ALL=(ALL:ALL) ALL`
No password	`NOPASSWD:`

Key takeaways:

sudo delegates root privileges without sharing the root password. Each command is authenticated and logged under the invoking user .
Group membership is the simplest grant. Add to sudo (Debian) or wheel (RHEL) and re-login .
The -a flag is critical. usermod -aG appends; usermod -G replaces all supplementary groups .
Group changes require a new session. Existing shells do not reload group memberships .
Fine-grained rules live in /etc/sudoers.d/. One file per role or team, edited with visudo -f .
Rule syntax is WHO WHERE=(AS_WHOM) WHAT. Absolute paths for commands; aliases for readability .
NOPASSWD: disables the prompt. Use sparingly—it reduces auditability .
visudo is mandatory. A syntax error in sudoers can revoke all sudo access .

Remember: sudo is the standard for delegated privilege escalation on Linux, and the /etc/sudoers file is its policy engine. Grant access through group membership for simplicity, or through explicit rules in /etc/sudoers.d/ for precision. Always use visudo—it validates syntax and prevents lockout. The -aG flag appends to groups; omitting -a can remove a user from essential groups. Group changes require a fresh login. Fine-grained rules use WHO WHERE=(AS_WHOM) WHAT, with absolute paths and command aliases for maintainability. For the LFCS exam, know both the group-based shortcut and the explicit rule syntax, and know why visudo exists.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!