How To Become Root in Linux: Security-Focused Techniques for Privilege Escalation

Root access on a Linux system is not a badge of honor—it’s a necessity and a liability. The root account (UID 0) carries absolute authority: every file, every process, all configuration. Mistakes here propagate system-wide. Security incidents often start with a misused root shell.

Problem: Root Shells Obscure Accountability

Too often, the first impulse is to drop to a root shell for convenience:

sudo su
# or
sudo -i

Both commands grant a persistent root environment. Yes, you can patch config files, restart daemons, or untangle broken packages. But the trade-offs:

• Audit trail lost—attribution is obscured. Only the initial use of sudo is logged, subsequent commands as root are not.
• Mistakes magnified—typos (“rm -rf / tmp” instead of “rm -rf /tmp”) have catastrophic results.
• Session exposure—an unattended root shell increases attack surface, especially in multi-user or remote environments.

If the idea is to temporarily fix one misbehaving systemd unit, running an entire session as root is overkill.

Best Practice: Use sudo Granularly

Single-command sudo is the correct default in most cases:

sudo apt-get update
sudo systemctl restart nginx

What do you get?

• Per-command logging in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS).
• Minimizes window of escalated privilege.
• (Usually) requires password input, deterring automated misuse.

For repetitive tasks, history can be searched for sudo, and you can review exactly who executed what.

Side Note

Some admins complain about typing sudo repeatedly. The trade-off is deliberate: safety over convenience. For multi-step scripts, consider building proper Ansible playbooks or integrating with configuration management systems, instead of relaxing privilege boundaries.

Single-Task Interactive Root Shells (with Caution)

When multiple root-level commands are required in sequence—kernel module debugging, for instance—an elevated shell does make sense. Consider the distinction:

• sudo -i: Gives you a full root login shell, running with root's environment (HOME=/root, etc).
• sudo -s: Keeps your environment but becomes root.

Example (tested on Ubuntu 22.04):

sudo -i
# Now in /root, with root's PATH
hostnamectl set-hostname test-node
exit

Important: Always exit back to your unprivileged shell—don’t leave terminals open as root.

su - and Legacy Environments

Some distros (notably RHEL derivatives pre-7, legacy UNIX, and air-gapped appliances) lack sudo or enforce separate root passwords.

su -
# prompts for the root password, not the user’s password

Observations:

• Most modern distributions disable root logins by default. Enabling root logins is not recommended unless absolutely required; update /etc/ssh/sshd_config and strong passwords if you must.
• su sessions are less auditable—rarely informative in logs beyond “session opened”.

Set the root password only when required:

sudo passwd root

Running Root GUI Applications

Launching graphical editors or tools as root (gedit, nautilus, etc.) with sudo is risky—can pollute user config files with root ownership. Use pkexec for PolicyKit-aware environments:

pkexec gedit /etc/fstab

Gotcha: pkexec depends on PolicyKit rules and may be unavailable in minimal installations.

Practical Example: Recovering a Broken Network Configuration

Network misconfiguration can lock you out—especially when working over SSH.

# Rescue run from a local console or recovery image
sudo -i
nano /etc/netplan/01-netcfg.yaml
netplan apply
exit

If you lose network despite precautions, you’ll be thankful you avoided staying root longer than required.

Non-Obvious Advice

• Use visudo exclusively. Editing /etc/sudoers directly is notoriously dangerous—one syntax error and all sudo access disappears. Always:

  sudo visudo
  

  This checks for syntax before writing.

• Audit sudoers by group, not individuals. Consider using group-based privilege (e.g., %wheel) to simplify access reviews.

• Protect from dangerous aliases. Sometimes, alias rm='rm -i' helps prevent accidental file deletions, but don’t rely solely on this under root—double-check paths, especially in scripts.

Quick Reference

Key Points

Privilege escalation is essential for system-level operations, but every method carries trade-offs. Default to sudo per command. Launch root shells briefly and intentionally. Never enable or persist a root login unless operational constraints demand it. Remember: a misused root shell will not forgive careless typing.