Overview

Almost every access decision on a Linux host reduces to two questions: who is this process, and is this identity allowed to touch that resource? Get the answers right and the system is hard to abuse. Get them wrong, with a stray world-writable file, an over-broad sudo rule, or an unexpected setuid binary, and a normal user becomes root. This group is the heart of the foundation because privilege escalation, the goal of most local attacks, lives entirely inside these mechanisms. This overview frames the model; the sibling pages drill into each part.

The Identity Model

Linux identity is numeric. Every user has a UID and every group a GID; the names you see are a convenience mapped from files like /etc/passwd. A process runs with a UID, a primary GID, and a set of supplementary GIDs, all inherited from its parent. The kernel never reasons about names, only numbers.

UID 0 is special: it is root, and the kernel skips most permission checks for it. That single fact drives the whole discipline of Linux security. The goal is to keep untrusted code out of UID 0 and to make the code that legitimately holds it as small and as auditable as possible. Users & Groups covers how accounts are stored, the split between system and human accounts, and how passwords are aged and locked.

The Classic Permission Bits

The oldest and most common control is the rwx bit set: read, write, and execute, defined separately for the file’s owner, its group, and everyone else. It is simple, fast, and on every file. File Permissions covers the bits, octal notation, the subtle meaning of execute on a directory (it means “traverse”), and how umask sets defaults for new files.

The classic bits are coarse. They express exactly three audiences (owner, one group, other), so “give these five specific users write access and no one else” is impossible with bits alone. That gap is where the other pages come in.

Mechanism	Fills the gap of	Page
POSIX ACLs	More than one user/group per file	ACLs & Attributes
File capabilities	Granting one root power, not all of root	ACLs & Attributes
sudo	Letting a user run specific commands as root	Sudo
setuid/setgid	A program changing identity as it runs	Setuid & Setgid
chattr +i	Protection the owner cannot override	ACLs & Attributes

Delegating Privilege, And The Paths It Opens

Real systems need to grant privilege: a backup job must read every file, an admin must restart services. Linux offers several ways to delegate, and each is also an escalation path when misused.

• sudo runs a command as another user (usually root) under a policy in /etc/sudoers. A tight rule grants one command; a lazy NOPASSWD: ALL grants everything. Worse, even a “single command” rule can be a full root shell if that command can spawn one, the GTFOBins problem covered in Sudo.
• setuid binaries run with the file owner’s identity regardless of who launches them. passwd needs this to edit the shadow file. But any setuid-root binary with a bug is a direct route to root, which is why Setuid & Setgid teaches you to enumerate and audit them.
• capabilities split root’s power into pieces, so a program can bind a low port without being able to read every file. Granting the wrong capability, or leaving cap_setuid on a scriptable binary, reopens the escalation door.

The recurring theme: delegation is necessary, and every delegation is a target. Least privilege (grant the narrowest thing that works) is the defense that runs through all of it.

How To Work Through This Group

Read in order: Users & Groups, then File Permissions, then Sudo, Setuid & Setgid, and ACLs & Attributes. The later pages assume you understand UIDs and rwx bits. Each page ends with hands-on exercises in the lab; take a snapshot first, because you will deliberately create insecure configurations to see how they are exploited and fixed.

Practical Guidance

1. Think in UIDs, not usernames; the kernel does, and escalation bugs often hide behind a familiar name mapped to UID 0.
2. Default to least privilege: grant the narrowest permission, sudo rule, or capability that makes the task work.
3. Treat every delegation mechanism (sudo, setuid, capabilities) as an escalation path and audit it as one.
4. Prefer ACLs or capabilities over widening the classic bits when the classic model is too coarse.
5. Work the pages in order and exploit each weak configuration yourself in the lab; you learn the defense by defeating it.