Users, Authentication & Privilege: passwd, shadow, PAM & sudo
Every Linux investigation eventually comes down to one question: who could act as whom. This chapter covers how accounts, authentication, and privilege actually work under the hood, the account database, the PAM framework behind logins, and how sudo, su, and group membership decide what a user is allowed to become.
User Account Structure
Every local account on a Linux system is recorded as one line in /etc/passwd, the account database that the system and most tools consult first. Each line is a set of colon-separated fields, and reading them correctly is the starting point for any account review.
| Field | Meaning |
|---|---|
| Username | The login name tied to this account |
| Password placeholder | An x, meaning the real password hash lives in /etc/shadow, not here |
| UID | Numeric user ID that the kernel actually uses to enforce permissions |
| GID | Numeric ID of the account's primary group |
| Comment / GECOS field | Free-text field, usually a full name or description |
| Home directory | Where the account lands on login and stores its personal files |
| Login shell | The program started on login, for example a shell, or /usr/sbin/nologin for service accounts that should never get an interactive session |
The password hash itself, along with the aging rules around it, lives in a separate file for a reason.
| /etc/shadow Field | Purpose |
|---|---|
| Username | Matches the corresponding entry in /etc/passwd |
| Password hash | The actual hashed credential, never stored in the world-readable /etc/passwd |
| Last change date | When the password was last set |
| Minimum age | Days that must pass before the password can be changed again |
| Maximum age | Days after which the password expires and must be changed |
| Warning period | Days before expiry that the user starts getting warned |
/etc/passwd is readable by any user, which is why it never holds the real hash. /etc/shadow is restricted instead: RedHat-family systems typically leave it readable by root alone, while Debian-family systems own it root:shadow with group-read, so only root and the shadow group can read it. Either way the credential material stays out of reach of ordinary unprivileged accounts.
root entry is not a normal configuration, it is one of the classic backdoor indicators worth checking /etc/passwd for directly.PAM: Pluggable Authentication Modules
PAM is the framework that most Linux authentication actually runs through: console login, sudo, SSH, and many other services all call into it instead of implementing their own authentication logic. It is stackable, a single login can chain several checks together, and it is configurable per service.
Each service that uses PAM has its own configuration file under /etc/pam.d/, for example one for login, one for sudo, one for sshd. Each file defines which modules run, in what order, and whether a failure there is fatal to the whole authentication attempt.
- auth: verifies the user is who they claim to be, typically a password check
- account: checks account restrictions, such as expiry or time-of-day limits
- password: handles updating credentials
- session: sets up or tears down things needed for the session, such as mounting a home directory
sudo, su, and Privilege Escalation Basics
su switches you to another user's full session, and by default that means authenticating with the target account's own password. sudo instead runs a single command as another user, typically authenticated with your own password, and is governed by rules defined in /etc/sudoers that specify exactly which users can run which commands as which accounts.
That rule-based model is precise when configured well, but a single overly broad rule can hand a low-privilege user a direct path to root. Privilege escalation on Linux tends to fall into a small set of recurring categories.
| Vector | What It Looks Like |
|---|---|
| Misconfigured sudo rule | A user is allowed to run a command as root that, by design or oversight, gives them a path to a full root shell |
| SUID binary abuse | An unexpected or unfamiliar setuid binary, the kind of artifact covered in chapter 1, running with elevated privileges it shouldn't need |
| Writable cron job or script | A script or job run by a privileged account that a lower-privileged user can modify, a persistence angle chapter 4 covers further |
| Unpatched kernel vulnerability | A known local privilege escalation flaw in an outdated kernel version |
Privileged Group Membership
Group membership can grant privilege just as directly as a sudoers rule can, and it is easy to overlook during a quick account review.
| Group | Why It Matters |
|---|---|
root | Full system privileges, membership here is equivalent to being root |
sudo or wheel | Depending on the distribution, membership in one of these grants the ability to use sudo |
docker | Effectively root-equivalent, since the Docker daemon runs as root and a container can be used to reach and modify the host filesystem |
None of these groups look dangerous by name alone, which is exactly why an account-and-group audit is a standard early step in any Linux investigation. A quiet addition to docker or sudo can be just as significant as a new UID 0 account.
Auditing Accounts and Privilege
Pulling the threads from this chapter together, a practical account and privilege review follows a short, repeatable sequence.
This same checklist feeds directly into chapter 4's persistence hunting, since attackers who gain elevated privilege here almost always try to make it stick somewhere else on the system.
Key Takeaways
/etc/passwdis the world-readable account database, while/etc/shadowholds the actual password hash and aging fields, restricted to root (and theshadowgroup on Debian-family systems).- UID 0 means root privileges regardless of username, so a second UID 0 account is a real backdoor indicator to check for directly.
- PAM is the stackable, per-service framework behind most Linux authentication, configured through files under
/etc/pam.d/. - A backdoored PAM module sits in the authentication path for nearly everything, making PAM integrity a serious persistence and credential-theft concern.
suswitches to a full session using the target account's password, whilesudoruns a single command using your own password under rules in/etc/sudoers.- Privilege escalation commonly comes from misconfigured sudo rules, SUID binary abuse, writable privileged cron jobs, unpatched kernel flaws, or privileged group membership like sudo, wheel, or docker.
Knowledge Check
Click an answer to reveal the explanation.
You find a second account in /etc/passwd, alongside root, that also has UID 0. What does this indicate?
What is PAM, in the context of Linux authentication?
Why does membership in the docker group matter during a privilege audit?