Linux Security / Advanced: constrained design and verified change / Lesson 18

Review a least-privilege Linux worker design

Integrate identity, resource scope, execution policy, dependencies, diagnostics, and pending enforcement evidence.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Trace each protected outcome to a model, reference assumption, and required observation.
Write an honest readiness statement for the complete proposed design.

Define the worker’s useful and forbidden behavior

The fictional worker reads public schedules and writes derived summaries for one workshop scope. It must not read attendee contacts, alter host accounts, accept arbitrary output paths, or deliver results to an unreviewed destination. The change adds background processing and a persistent output directory, so identity lifetime and cleanup matter. Define those requirements before selecting a unit file or policy profile. The exercise uses only created labels and data; it starts no worker and touches no real account, file, service, firewall, network, package, device, or credential.

Check the business-level resource/action relation

The first program permits two exact resource/action pairs and rejects a protected contact read and an arbitrary output. It is an application policy model, not DAC, AppArmor, or a filesystem resolver. A real implementation obtains trusted subject and resource context and enforces the rule before protected effects. The model deliberately avoids interpreting path text as object authority. Keep the allowed relationship narrow enough to review, and include a legitimate success so an all-deny implementation does not satisfy the design. Exact expected cases make the policy’s purpose visible to another reviewer.

python Check exact synthetic resource/action pairs

allowed = {("public-schedule-w4", "read"), ("summary-w4", "write")}
def permits(resource, action):
    return (resource, action) in allowed

assert permits("public-schedule-w4", "read") is True
assert permits("summary-w4", "write") is True
assert permits("attendee-contacts-w4", "read") is False
assert permits("arbitrary-output", "write") is False
print("four resource-action cases preserve the declared worker scope")

Expected output

four resource-action cases preserve the declared worker scope

The complete program compares strings in memory and reads or writes no resource. It implements none of the actual operating-system layers. Its passing result establishes only the declared application relation.

Assign each enforcement question to its layer

Identity and groups, ordinary permissions and ACLs, service filesystem view, mandatory policy, capability transitions, network scope, package trust, and recovery each support different claims. Do not assume one directive establishes all of them. The second program compares required evidence boundaries with a declared verified subset and names what remains. It runs no named platform check. This prevents a locally correct business policy from being presented as a complete Linux deployment verification. The actual design needs version-specific support, effective loaded state, observed allowed/denied behavior, and documented failure handling at the selected boundaries.

python Preserve unverified platform boundaries in the package

required = {"application-scope", "dac-acl", "service-view", "mandatory-policy", "artifact-trust"}
verified = {"application-scope"}
pending = sorted(required - verified)
assert pending == ["artifact-trust", "dac-acl", "mandatory-policy", "service-view"]
assert not required <= verified
print("local application scope leaves four platform boundaries pending")

Expected output

local application scope leaves four platform boundaries pending

The complete program checks a fictional evidence inventory. It performs no permission, service, mandatory-policy, or artifact verification. The verified label is classroom metadata and must be backed by actual outputs in a real package.

Review transitions and recovery alongside startup

A design must consider updates, account/group changes, output replacement, key or endpoint changes, log retention, backup recovery, and failed work. The worker may start correctly while a later transition broadens authority or restores an old weakness. Keep cleanup ownership and denied side effects explicit. No actual lifecycle operation occurs in this exercise. An approved implementation should verify the relevant transitions in disposable owned fixtures and retain meaningful regressions. Do not substitute a universal hardening score, command sequence, or undocumented fallback for a reviewed model of what the worker must preserve over time.

Write the bounded readiness statement

The local resource/action policy passed its stated synthetic cases, and the evidence inventory retained four unverified platform boundaries. That is the supported result. No Linux host was assessed, hardened, scanned, configured, restarted, or tested for actual enforcement. Named Ubuntu 24.04, Linux, systemd, AppArmor, nftables, APT, and OpenSSH references explain assumptions, not deployed guarantees. A useful handoff identifies the exact approved observations needed next and the accountable decision owner. Clear limits let the design be concrete and reviewable without pretending that educational models performed administrative or security operations.

Common errors and fixes

The local policy result becomes complete Linux assurance

Why it happens: Operating-system and deployment boundaries disappear.
How to fix it: List pending layers and attach evidence separately.
Prevent it next time: Keep conclusion strength within actual execution scope.

A successful startup proves lifecycle safety

Why it happens: Later authority, updates, and recovery are omitted.
How to fix it: Review relevant transitions and failure invariants.
Prevent it next time: Include lifecycle triggers in the design record.

Resource labels are treated as actual file access tests

Why it happens: An application model is confused with kernel enforcement.
How to fix it: State the model and verify real resource identity separately when authorized.
Prevent it next time: Preserve intended, loaded, and observed evidence distinctions.

Check your understanding

1. The capstone policy denies contacts but DAC/ACL is pending. What can be concluded?

Show worked solution

The declared application relation rejected the synthetic contact resource. It does not prove the real process cannot access contact files. Keep the operating-system boundary unverified and identify the approved environment-specific observation needed before making that claim.

2. Write the handoff result for the complete course exercises.