Runtime Capability & Ambient Set Audit (getpcaps) Prompt
Audit what Linux capabilities a running process actually holds across its permitted/effective/inheritable/ambient/bounding sets, and decide whether a service is over-privileged or whether a 'permission denied' is a missing capability.
- Target user
- Linux admins debugging privilege drops or hardening services with fine-grained capabilities
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior Linux security engineer fluent in the five capability sets (Permitted, Effective, Inheritable, Bounding, Ambient) and how they transform across execve and across a systemd unit's privilege drop. I will provide: - The symptom: an unprivileged service failing with EPERM/EACCES, OR a hardening goal (drop a root service to least privilege) - `getpcaps <pid>` for the running process (and the parent if relevant) - `getcap` on the binary if it's file-capability based - The systemd unit's `User=`, `AmbientCapabilities=`, `CapabilityBoundingSet=`, `NoNewPrivileges=` (or the container's `--cap-add`/`--cap-drop`) - The exact operation that's failing and the strace EPERM line if I have it Your job: 1. **Decode the five sets for THIS process** — explain what's in Permitted vs Effective vs Inheritable vs Bounding vs Ambient right now, and what each set governs. 2. **Map the failure to a missing capability** — for an EPERM, identify the specific capability the failing syscall needs (e.g. binding port <1024 = CAP_NET_BIND_SERVICE; setting time = CAP_SYS_TIME; chown = CAP_CHOWN) and which set it's missing from. 3. **Explain the execve transform** — show why a capability in Inheritable alone is useless without either a matching file Inheritable bit or the Ambient set, and how `NoNewPrivileges=` and the Bounding set clamp what can ever be gained. 4. **Right-size the grant** — for a hardening goal, identify the *minimal* capability set the service truly needs and the exact `AmbientCapabilities=` / `CapabilityBoundingSet=` lines (or file caps via `setcap`) to grant only those, dropping the rest. 5. **Verify** — give the post-change `getpcaps` you'd expect to see and a functional test that the service still works with the reduced set. Output as: (a) a table of the five sets and their current contents in plain language, (b) the precise capability that's missing or excess for this case, (c) the exact unit directives or `setcap` command to fix it, (d) the expected post-change `getpcaps` and a functional verification step. Verify before acting: never add a broad capability (or `CAP_SYS_ADMIN`, the "new root") to silence an EPERM — identify the one specific capability the syscall needs, and test the minimal grant in staging before production.
Why this prompt works
Linux capabilities are powerful and almost universally misunderstood, because the model isn’t one privilege flag — it’s five interacting sets (Permitted, Effective, Inheritable, Bounding, Ambient) whose contents transform across execve in non-obvious ways. The single most common confusion is expecting an Inheritable capability to “carry through” to a child, when in reality it does nothing without a matching Ambient entry or file Inheritable bit. This prompt makes the AI decode all five sets for the actual running process from getpcaps, so you’re reasoning about reality instead of intuition.
For the debugging case, the leverage is mapping an EPERM to exactly one capability. Binding a low port needs CAP_NET_BIND_SERVICE, not root; changing the clock needs CAP_SYS_TIME; chowning needs CAP_CHOWN. The prompt forces the model to name the specific capability the failing syscall requires and the specific set it’s missing from — which is what stops the lazy and dangerous fix of bolting on CAP_SYS_ADMIN (effectively root) just to make the error go away.
For the hardening case, it inverts the same skill: find the minimal set a root service actually needs, then write the exact AmbientCapabilities= and CapabilityBoundingSet= directives (or setcap file caps) to grant only those and clamp everything else, ideally with NoNewPrivileges=. Because capability changes are easy to get subtly wrong, the prompt insists on a predicted post-change getpcaps and a functional test. The AI drafts the least-privilege grant and predicts the result; you verify the service still works with the reduced set before shipping it.