Linux privilege escalation

A fictional museum runs a Linux service that makes nightly copies of its collection catalog. The service needs to read the catalog and write backups. It does not need to manage every account on the machine. Understanding that difference is the foundation of privilege security: give useful work enough authority, then protect the places where that authority is assigned or changed.

Start with the process, not its name

A process carries user and group credentials. Its Effective user ID helps determine authority; Linux also has filesystem IDs that normally follow effective IDs. A friendly service name does not tell you these values. Supplementary groups can provide important access even when the account is not root.

For an ordinary file without additional controls, the matching owner, group, or other class supplies the relevant mode permissions. These classes are not added together. Follow process identity and file permissions before exploring ACLs.

Separate the file from its location

Reading file content, writing it, and changing its directory entry are different operations. A directory governs names and traversal; a file governs its contents. Protecting the museum’s configuration file therefore includes reviewing its containing directories and the process that creates replacements.

Default permissions influence newly created objects, while existing files retain their own settings. Continue with directory permissions and creation masks.

EXPLORE THE CONCEPT

Try a Linux permission decision

Explore the cases, then change the identity and permissions. This model covers read and write access to an ordinary file with no ACLs, extra capabilities, or additional policy.

The owner cannot borrow the group grant

In the ordinary mode-bit model, a matching owner uses the owner class. If owner write is off, a group write grant does not supply a second attempt, even when the owner also belongs to that group.

A directory is a different kind of object

Directory read lists names; search permits traversal. Changing directory entries normally needs write and search. This file simulator does not decide directory deletion, renaming, or traversal.

Real systems include more controls

ACLs, process capabilities, mount restrictions, and mandatory security policy can affect actual access. Use the simulator to understand one mechanism, then examine the full context when reviewing a system.

A simplified learning model. It connects to no systems and uses no real data.

Understand deliberate changes in authority

SUID on a supported executable can change the effective user ID to the file owner’s ID. It does not unconditionally make every program run with every owner privilege. Linux ignores these bits on interpreter scripts, and restrictions such as no_new_privs or a nosuid mount can prevent the transition. Ask what purpose a privileged helper serves and how its authority is constrained.

sudo applies policy to delegated tasks: who may perform which work, as whom, and under what conditions. Review arguments, environment, configuration, and dependencies alongside the task itself. A Capability separates particular privileged operations, but a short list of capabilities can still grant substantial power. Explore special permissions, delegation policy, and capability boundaries.

Follow the service’s trusted dependencies

The museum’s backup identity is only one part of its Trust boundary. Its schedule, program, configuration, libraries, management interface, and destination also influence the work it performs. Changing a trusted dependency may alter the behavior of a powerful service. Give each component an owner and limit who may maintain it.

Local sockets still need authorization. Container management groups may carry considerable host authority. Mount restrictions and mandatory policy address particular operations, with defined limits. The short lessons on scheduled work, local sockets, and mandatory controls unpack those boundaries.

Verify a useful boundary

State the requirement plainly: “The backup worker may read the catalog and create backups; only the maintenance role may change its configuration.” Remove unnecessary grants, verify ordinary work still succeeds, and confirm that disallowed actions are rejected. Review the running configuration after updates. Supported software, timely maintenance, change records, and tested recovery complement permission design; none makes the others unnecessary.

Apply these ideas in the Linux permission-review case. Work from supplied access records, distinguish old files from new-file policy, and write a justified correction with clear acceptance evidence.