Lab 03 — Privilege Boundary Reviewer

Difficulty: 3/5 | Runs locally: yes

Pairs with the Phase 05 WARMUP Chapters 2, 5, 9 (Linux capabilities, Windows privileges, macOS entitlements) and the advanced token-escalation lab.

Why This Lab Exists (Purpose & Goal)

"Least privilege" is easy to say and hard to verify, because privilege on a modern OS is not one number — it is a set of fine-grained grants (Linux capabilities, Windows token privileges, macOS entitlements), most of which look innocuous and a few of which are near-equivalent to owning the machine. The goal of this lab is to build the reviewer that compares a granted privilege set against a service's declared requirements and flags the gap: broad authority, unexplained rights, and grants with no justification.

The Concept, In the Weeds

The review hinges on a few facts that trip up beginners:

Some grants are far more dangerous than they look. CAP_SYS_ADMIN on Linux is so broad it's nearly root. SeImpersonatePrivilege / SeDebugPrivilege / SeBackupPrivilege on Windows each lead to SYSTEM. A powerful macOS entitlement (disable-library-validation, private frameworks) can enable abuse. The reviewer must know which grants matter.
Every grant needs a justification tied to a feature. A privilege with no documented reason is a finding — not because it's definitely exploited, but because unexplained authority is unmanaged risk: nobody can say whether removing it is safe, so it accretes forever.
A grant is a finding when it's unjustified or chainable, not merely present. A service account normally holds SeImpersonatePrivilege; the finding is "this service is one RCE from SYSTEM, harden and monitor it," not "someone misconfigured this." Calibration again (the Phase 04 lesson).

Why This Matters for Protecting the Company

Privilege accretes silently — a grant added for a one-time need, never removed; a service deployed with the vendor's over-broad defaults. Over time the fleet drifts toward over-privilege, and every excess grant is an escalation primitive waiting for the next code-execution bug. A privilege-boundary reviewer lets a security team continuously measure and shrink that surface, justify what remains, and catch the dangerous grants (the ones that turn a foothold into full control). This is the difference between an RCE that's contained and one that becomes domain admin.

Build It

Implement the reviewer: compare a normalized Linux capability / Windows privilege / macOS entitlement set against declared service requirements; flag broad authority, unexplained rights, and missing justification.

LAB_MODULE=solution pytest -q
# populate profiles from owned endpoints with platform-native inspection (whoami /priv, capsh, codesign -d)

Secure Implementation Patterns

The reviewer — needed × broad × justified, per platform (mirrors solution.py):

BROAD = {                                      # near-equivalent-to-owning-the-box grants
    "linux":   {"CAP_SYS_ADMIN", "CAP_SYS_MODULE", "CAP_DAC_READ_SEARCH"},
    "windows": {"SeDebugPrivilege", "SeTcbPrivilege", "SeLoadDriverPrivilege"},
    "macos":   {"com.apple.security.cs.disable-library-validation",
                "com.apple.security.get-task-allow"},
}

def review(platform, granted, required, justifications) -> tuple[str, ...]:
    if platform not in BROAD: return ("UNSUPPORTED_PLATFORM",)
    findings = []
    for item in sorted(granted):
        if item not in required:                          findings.append(f"UNNEEDED:{item}")     # over-grant
        if item in BROAD[platform]:                        findings.append(f"BROAD:{item}")        # dangerous power
        if not justifications.get(item, "").strip():       findings.append(f"UNJUSTIFIED:{item}")  # unmanaged risk
    for item in sorted(required - granted):                findings.append(f"MISSING_REQUIRED:{item}")
    return tuple(sorted(findings))

Three independent checks compose the boundary: unneeded (granted but not required → remove), broad (a near-root power → scrutinize even if "needed"), and unjustified (no feature-tied reason → a finding, because unexplained authority only ever accretes).

Production practices to carry forward:

Every grant maps to a concrete feature/data-flow — if you can't justify it, remove it.
Calibrate: a grant is a finding when unjustified or chainable, not merely present — a service account normally holds SeImpersonatePrivilege, so the action is "harden/monitor that service," not "fix the privilege" (see the token-escalation lab).
Privilege accretes — schedule periodic access reviews; the default drift is always toward over-privilege.
Feed flagged grants into escalation-path analysis (Phase 05 lab-04, Phase 07 IAM) to see what they actually reach.

Validation — What You Should Be Able to Do Now

Identify the high-impact grants on each OS (CAP_SYS_ADMIN; SeImpersonate/SeDebug/SeBackup; powerful entitlements) and explain why each is dangerous.
Require a feature-tied justification for every grant, and treat unexplained authority as a finding.
Calibrate: flag a grant when it's unjustified or chainable, not merely because it exists.

The Broader Perspective

This lab generalizes the single most important idea in access control: authority must be minimal, justified, and continuously reviewed — because unmanaged grants only ever accumulate. That is the same principle behind cloud IAM least privilege and access reviews (Phase 07), behind sandbox authority enumeration (Phase 06), and behind AI-agent tool scoping (Phase 11). The reviewer you built here is a miniature of the IAM attack-path analysis you'll do at cloud scale — both answer "what is granted, is it needed, and what can it reach?" Privilege you can't justify is privilege you should remove.

Interview Angle

"A service account has SeImpersonatePrivilege — is that a vulnerability?" — It's normal, but it means an RCE in that service reaches SYSTEM; the action is to harden/monitor that service, not "fix the privilege." (See the token-escalation lab.)
"How do you justify a privilege?" — Map it to a concrete feature and data flow; if there's no mapping, it's a finding to remove or document.

Extension (Stretch)

Feed real profiles from owned endpoints, and chain this with the token-escalation analyzer to turn flagged privileges into user → SYSTEM paths.

References

Phase 05 WARMUP Chapters 2, 5, 9; capabilities(7); Windows privilege constants; Apple entitlements reference.

Security Engineer