Linux Security / Basic: identity, resources, and evidence / Lesson 5

Review process authority and Linux capabilities

Distinguish numeric identity, retained authority, capability sets, and privilege changes across execution.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain why non-root alone is not a complete privilege boundary.
State what no_new_privs constrains without treating it as a full sandbox.

List what a process can actually do

A process with a nonzero uid can still hold capabilities, open descriptors, writable resources, delegated access, or broad application authority. Conversely, changing one identifier does not automatically remove every previously obtained resource. Review the whole authority path rather than attaching a safe label to non-root. Linux capabilities divide privileged operations into units, but some units cover broad families of behavior. A service should receive only the authority its actual work requires. This course reasons over invented sets and reads no process credentials, file capabilities, descriptors, or live kernel state.

Compare capability grants with a specific workload

The report worker’s classroom design requires no privileged network binding or host administration. The first program flags two proposed capability labels as outside that declared need. CAP_SYS_ADMIN is especially broad and should not be treated as a narrow convenience switch; exact behavior remains kernel and namespace dependent. The calculation is not a capability evaluator and does not inspect effective, permitted, inheritable, bounding, or ambient sets. Those sets and execution transitions have their own documented semantics. A real design must verify actual process authority, not merely an empty desired list in a configuration record.

python Inspect a fictional capability proposal as plain data

required = set()
proposed = {"CAP_NET_BIND_SERVICE", "CAP_SYS_ADMIN"}
excess = proposed - required
assert excess == proposed
assert "CAP_SYS_ADMIN" in excess
assert not required
print("two capability labels exceed the declared report-worker need")

Expected output

two capability labels exceed the declared report-worker need

The complete program compares string sets and performs no capget, capset, executable attribute, uid transition, or kernel query. The required set is a classroom design assumption, not an assessment of a real executable.

Understand the boundary of no_new_privs

The Linux no_new_privs flag constrains privilege gains through execve under its documented semantics and is inherited once set. It does not revoke existing authority, close open resources, replace file permissions, or establish a complete containment boundary. The planning record pairs the flag with an explicitly unreviewed existing-authority state. It is non-runnable data and sets no flag. A real launcher or service manager must integrate the feature with other policy transitions correctly; upstream documentation notes interactions with Linux security modules. Avoid copying one setting and declaring every executable or child process safely sandboxed.

json A no_new_privs review record that preserves missing evidence

{"workload":"report-worker-lab","proposedNoNewPrivileges":true,"existingAuthorityReviewed":false,"openResourcesReviewed":false,"capabilityTransitionVerified":false,"actualFlagSet":false}

The non-runnable JSON records a proposal and unresolved questions. It changes no process flag and proves no enforcement. The true proposed value must not hide the false review and verification fields.

Review privileged helpers and inherited resources

A small privileged helper can reduce authority in the main workload only when its interface, caller checks, input handling, and resource scope are narrow and verified. An unrestricted helper that accepts arbitrary paths or commands can restore the broad authority the split was meant to remove. Inherited descriptors and environment can also cross the boundary, so define what is intentionally passed. The lesson provides no setuid program, privilege-escalation test, or operational helper. It teaches how to ask whether delegation reduces capability or merely moves it behind an unreviewed interface.

Observe actual authority only through approved checks

An approved isolated verification plan should include legitimate work, denied administrative effects, capability transitions, and resource inheritance relevant to the service. Record the kernel and launcher assumptions and distinguish desired, loaded, and effective state. No such host operations run here. The local set check and JSON review establish policy reasoning only. A precise report says which grants were unnecessary under the fictional workload and which real transitions remain untested, without claiming that a non-root uid, empty list, or no_new_privs proposal alone secures a Linux process.

Common errors and fixes

Non-root is reported as no privilege

Why it happens: Other authority and inherited resources are ignored.
How to fix it: Inventory capabilities, descriptors, writable resources, and delegated interfaces.
Prevent it next time: Review effective authority rather than one uid field.

CAP_SYS_ADMIN is granted as a small workaround

Why it happens: A broad capability hides the actual required operation.
How to fix it: Identify the narrow operation and review a smaller design.
Prevent it next time: Require rationale and actual enforcement evidence for every grant.

no_new_privs is called a complete sandbox

Why it happens: Exec privilege constraints are expanded to every resource boundary.
How to fix it: State its documented scope and review existing authority separately.
Prevent it next time: Pair each control with a specific claim and test boundary.

Check your understanding

1. A worker has no new privilege gain but retains a writable sensitive descriptor. Is that protected by the flag alone?

Show worked solution

No. The flag’s exec-related promise does not revoke the already available resource. Review descriptor inheritance and the actual permitted write boundary separately. The classroom example performs no descriptor inspection or process transition and cannot establish a real service’s authority.

2. Why is an empty required capability set not a universal recommendation?