Root, sudo and Superuser Accounts on Linux and Unix

On Linux and Unix, whoever runs code as UID 0 owns the machine, and most estates have far more routes to UID 0 than anyone has written down. Root is reached by direct login, SSH, su, sudo, setuid programs, services that start as root and processes holding powerful capabilities, and each route needs its own control. This guide treats the superuser as a privileged account to be governed: how to lock down the root account itself, how su and sudo should be configured through PAM, how to shrink the setuid and capability footprint, how to log every use of root, and how to keep a break-glass path that works when directory services fail. It is for Linux administrators, platform engineers and PAM teams. Detailed sudoers rule design is in the sudo and sudoers Security Guide; this page covers the whole superuser picture around it.

Key takeaways

Root is a UID, not a name. Any account with UID 0 has root's powers, and the capabilities manual notes that a process with effective UID 0 bypasses all kernel permission checks, so inventory UID 0, not just the account called root.
Close direct root logins. Set PermitRootLogin no in sshd (the default is prohibit-password, which still allows key login) and make administrators authenticate as themselves first.
Locking a password is not disabling an account. The passwd manual warns that passwd -l leaves SSH key logins working; disable access paths explicitly.
Every route to UID 0 needs logging. sudo event and I/O logs, su failures in btmp, setuid execution and root process starts all belong in central logging, out of root's reach on the host.
Keep one tested break-glass path. A vaulted local credential or console route that works without the directory, with alerts on every use, is safer than leaving root open "just in case".

What makes an account a superuser

Unix privilege is tied to the user ID. The account named root is simply the conventional holder of UID 0. The Linux capabilities manual describes the traditional model: a process with effective UID 0 bypasses all kernel permission checks, while other processes are checked against their credentials. Linux then splits root's powers into separately controllable capabilities, which matters because a process can hold some of root's power without being UID 0.

Route to superuser power	How it works	Primary control
Direct root login	Console, serial or SSH login as root	Disable remote root login; restrict console access; vault the password
su	Switches to root after authenticating with the root password, via PAM	Restrict to a group with `pam_wheel`, or remove the need for the root password entirely
sudo	Runs a command as root after authenticating the invoking user, per sudoers policy	Named rules, MFA, I/O logging, central policy
Other UID 0 accounts	Any extra entry in `/etc/passwd` with UID 0, often a leftover or a persistence trick	Regular UID 0 inventory; alert on any new one
setuid-root programs	Executables that run with the owner's UID (root) regardless of caller	Minimise, inventory, monitor changes; mount untrusted filesystems `nosuid`
File and process capabilities	Specific powers such as `CAP_DAC_OVERRIDE` or `CAP_SYS_ADMIN` attached to files or processes	Grant narrow capabilities, never `CAP_SYS_ADMIN` where avoidable; inventory file capabilities
Root services and agents	Daemons, configuration-management agents, backup and monitoring agents running as root	Run as dedicated users with capabilities; protect their credentials as privileged NHIs

Controlling the root account itself

Remote login

PermitRootLogin: the sshd_config manual lists four values: yes, prohibit-password, forced-commands-only and no. The default is prohibit-password, which disables password and keyboard-interactive authentication for root but still allows public key login. Many hardened estates still have root keys in /root/.ssh/authorized_keys from image builds. Set no unless a specific automated job needs root, and then use forced-commands-only with a command-restricted key.
Group allow lists: AllowGroups limits SSH login to members of named groups; DenyUsers refuses named users and is processed before AllowUsers. Use an admin group allow list so that only named accounts can log in at all. See the OpenSSH Server Hardening Guide.

Password and account state

Locking versus disabling: passwd -l prepends ! to the stored hash so no password matches. The passwd manual is explicit that this does not disable the account: the user may still log in with another token such as an SSH key. To disable an account it points to usermod --expiredate 1. For root, most estates lock the password and remove SSH access rather than expire the account, so that console recovery still works.
Status checks: passwd -S root shows L (locked), NP (no password) or P (usable password). NP on root is a critical finding.
If a root password exists: make it long and random, unique per host, held in a vault with check-out and rotation after use. Never share one root password across a fleet. The same pattern as Windows LAPS applies; see the Local Administrator Password Solution (LAPS) Guide for the model.

Other UID 0 entries

Check every host for accounts other than root with UID 0 in /etc/passwd and in directory sources. There is almost never a legitimate reason for a second UID 0 account, and ATT&CK lists local account creation (T1136.001) as a persistence technique. Treat any new UID 0 entry as an incident until explained.

su, sudo and the PAM stack

Both su and sudo authenticate through PAM, so the PAM configuration decides who can become root and how.

Setting	Where	Effect and guidance
`auth required pam_wheel.so use_uid`	`/etc/pam.d/su` (and `su-l` for `--login`)	Only members of the wheel group (or GID 0 if no wheel exists) can su to root. `use_uid` checks the caller's real UID rather than the login session. `group=name` uses a named group instead.
`pam_wheel.so trust`	su	Lets wheel members become root without a password. Avoid: it removes the authentication step.
sudo authentication	`/etc/pam.d/sudo`	Add MFA here (a PAM module for your MFA provider) so elevation needs a second factor, not just the user's password.
`Defaults timestamp_timeout`	sudoers	Credential cache lasts 5 minutes by default; reduce for full administrators, or set 0 to prompt every time.
`rootpw`, `targetpw`, `runaspw`	sudoers	Make sudo ask for the root or target password. This reintroduces a shared secret and loses individual accountability; normally leave off.
`Defaults env_reset`	sudoers	On by default: commands run in a minimal environment. Keep it, and set `secure_path`.
`Defaults use_pty`	sudoers	Runs the command in a new pseudo-terminal, which limits terminal injection by background processes.

Prefer sudo over su for people: su to root needs the root password, which is shared by definition. sudo authenticates the individual and logs who did what. Many distributions now lock root and rely on a sudo group from installation.
Use runuser in scripts: the su manual recommends runuser for privileged callers such as root-run scripts, because it is not setuid and needs no authentication, and setpriv where no PAM session is needed.
Do not hand out ALL: the sudoers manual describes ALL as a reserved word that always matches and warns that using it "can be dangerous". When a command rule is ALL, SETENV is implied, so users can also set environment variables. Full administrator rules should be few, named and logged.

For rule syntax, aliases, wildcards and service account rules, use the sudo and sudoers Security Guide. ATT&CK tracks abuse of sudo and its credential cache as T1548.003 Sudo and Sudo Caching.

setuid programs and capabilities

A setuid-root program runs as root whoever starts it. The capabilities manual adds that when a set-UID-root program runs, the kernel treats its capability sets as fully set, so the process gets every capability its bounding set allows. Every setuid binary is therefore a small part of your root attack surface, and abuse of setuid and setgid is ATT&CK T1548.001.

Inventory: list all setuid and setgid files on each image (a filesystem search for the setuid permission bit) and record the expected set. Compare every build and alert on additions.
Remove what you do not need: drop setuid from tools nobody uses on servers, or remove the packages.
Mount options: mount /tmp, /home, removable media and data volumes with nosuid so setuid files placed there do not take effect.
Replace setuid with capabilities: since Linux 2.6.24 capabilities can be attached to executables with setcap, stored in the security.capability extended attribute. A web server that only needs low ports can be given CAP_NET_BIND_SERVICE instead of starting as root.
Avoid CAP_SYS_ADMIN: the manual calls it overloaded and says "Don't choose CAP_SYS_ADMIN if you can possibly avoid it!". CAP_DAC_OVERRIDE and CAP_SETUID are close to root in practice; treat them as such in reviews.

Permission bits, setgid directories and ACLs are covered in depth in the Linux File Permissions, SUID and ACLs Guide.

Logging every use of root

Source	What it records	Setting or location
sudo event log	Who ran which command as whom, from where, and denials	syslog by default; `logfile` for a file
sudo I/O log	Terminal input and output of the session, replayable with `sudoreplay`	`log_input`, `log_output` (both off by default)
sudo subcommand log	Child processes spawned by an elevated command, such as a shell from an editor	`log_subcmds` and `intercept` (sudo 1.9.8 and later)
Central sudo log server	Event and I/O logs shipped off the host, stored locally or relayed onward	`sudo_logsrvd`, configured in `/etc/sudo_logsrvd.conf`
su failures	Failed su attempts	btmp file (su never writes lastlog)
SSH authentication	Root and admin logins, key fingerprints	sshd logs via syslog or the journal
Kernel audit	Process execution with effective UID 0, changes to `/etc/passwd`, `/etc/shadow`, `/etc/sudoers` and `sudoers.d`	Linux audit framework rules

A user with full root on a host can edit local logs, so ship logs off the host in near real time and keep them where host administrators cannot alter them. sudo_logsrvd exists for exactly this for sudo I/O logs.

Break-glass root

Most root lockdowns assume the directory, the MFA service and the PAM tool all work. When they do not, someone still needs to recover the host. Plan that path deliberately; see the Break-Glass Account Guide for the general model.

Choose the route: usually a unique random root password per host, held in a vault or sealed offline store, usable only at the console, serial or out-of-band management interface, not over SSH.
Protect the out-of-band layer: hypervisor consoles, cloud serial consoles and BMC interfaces give root-equivalent recovery. Restrict and log access to them as tightly as root itself.
Alert on every use: any console root login or vault check-out raises an alert to the security team.
Rotate after use: change the credential once the incident is closed.
Test twice a year: recover a non-production host using only the break-glass path, with directory and MFA unavailable, and record the time taken.

Rolling out root controls

Discover: for every host, collect UID 0 accounts, root password status, root authorized_keys, sshd PermitRootLogin, sudoers rules including sudoers.d, setuid and capability files, and root-running services.
Baseline in images: fix new builds first: root password locked, no root keys, PermitRootLogin no, admin group allow list, pam_wheel on su, sudo logging on.
Pilot on one ring: apply the baseline to a small server group, confirm administrators and automation still work through named accounts and sudo, and watch for failed jobs.
Move automation off root: configuration management, backup and monitoring agents that SSH in as root should use a dedicated account with scoped sudo rules or a local agent.
Roll out by ring: extend to wider groups through configuration management, keeping the old sshd and PAM files for rollback.
Centralise logs and alerts: ship sudo, auth and audit logs off host; add alerts for the events in the detection section.
Review quarterly: who holds full administrator rules, which setuid files appeared, which hosts drifted.

Small versus large estates: a small team can manage sudoers in configuration management with a single admin group and a vaulted root password per host. Large estates usually centralise policy (directory-backed sudo rules or a PAM platform issuing time-bound elevation), add session recording and integrate approvals. See the Admin panels and super admin accounts guide for the governance side.

Where identity fits

Many root-capable identities are not people: deployment pipelines, configuration-management agents, backup tools and monitoring systems often hold SSH keys or sudo rules that reach root on hundreds of hosts. They are non-human identities with the highest privilege in the estate. Give each an owner, scope its sudo rules to exact commands, keep its keys short-lived or certificate-based, and rotate on change of ownership. See the SSH Key Management Guide and the SSH Protocol and Certificate Authority Guide.

Detection and measurement

New UID 0 account or change to /etc/passwd, /etc/shadow: high-priority alert.
Change to sudoers or sudoers.d: alert, and compare against configuration management.
Direct root login over SSH or console: alert on every occurrence once remote root is disabled.
Repeated sudo or su failures: possible guessing or misuse of a compromised account.
Shells spawned from elevated commands: visible through log_subcmds or audit rules.
New setuid file or file capability: outside a package update window.

Metric	Target
Hosts with `PermitRootLogin no` (or a documented exception)	100 percent
Hosts with a root password that is unique and vaulted, or locked	100 percent
Hosts with UID 0 accounts other than root	Zero
Accounts holding full administrator sudo rules	Small, named and reviewed quarterly
Hosts shipping sudo and auth logs centrally	100 percent
Break-glass tests passed in the last six months	At least one per platform

Common failure patterns

Relying on the default PermitRootLogin. prohibit-password looks safe but allows root key logins, and image builds often leave a root key behind.
Thinking a locked password disables root. As the passwd manual notes, SSH keys still work on a locked account.
One root password across the fleet. A single leak or ex-employee gives root everywhere.
Automation logging in as root. Shared root keys for configuration management mean no attribution and a single key that compromises everything.
ALL rules and shell escapes. Broad sudo rules, or narrow rules for editors and interpreters that can spawn shells, give full root without any log of what followed.
Logs left on the host. A root user can remove the evidence of their own actions if logs are not shipped off the box.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	AC-6(2), AC-6(5), AC-6(9), AC-6(10)	Non-privileged accounts for normal work, restricted privileged accounts, logging and prohibiting privileged functions
NIST SP 800-53 Rev 5	IA-2(1)	MFA for privileged accounts, including sudo elevation
NIST SP 800-53 Rev 5	AU-2, AU-12, AU-9	Logging root use and protecting the logs from root on the host
NIST SP 800-53 Rev 5	CM-6, CM-7	sshd, PAM and sudoers baselines; removing unneeded setuid programs
NIST CSF 2.0	PR.AA-05, PR.PS-04, DE.CM-03	Privilege policy, log generation and monitoring of privileged activity
ISO/IEC 27001:2022 Annex A	A.8.2 Privileged access rights; A.8.15 Logging	Allocation and review of root rights; recording their use
CIS Controls v8.1	Control 5 Account Management; Control 6 Access Control Management	Dedicated admin accounts, MFA for administrative access
MITRE ATT&CK	T1548.003, T1548.001, T1078.003, T1136.001, T1021.004	sudo abuse, setuid abuse, local account use and creation, SSH lateral movement

Practitioner checklist

Set PermitRootLogin no and remove root authorized_keys on every host, documenting any exception.
Lock the root password, or make it unique per host and vaulted with rotation after use.
Alert on any UID 0 account other than root.
Restrict su with pam_wheel.so use_uid and prefer sudo with MFA for people.
Turn on sudo I/O logging and log_subcmds for full administrators and ship logs off host.
Inventory setuid files and file capabilities per image and alert on drift.
Move automation from root logins to scoped accounts with exact-command sudo rules.
Define and test a console-only break-glass path at least twice a year.

Root, sudo and superuser accounts on Linux and Unix: controlling UID 0 end to end