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.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
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.
Related prompts
-
systemd Unit Hardening Review Prompt
Audit a systemd service unit and add sandboxing directives (NoNewPrivileges, ProtectSystem, capability bounding, syscall filters) to shrink its blast radius without breaking the workload.
-
Linux Capabilities Audit & Hardening Prompt
Audit POSIX file capabilities and per-process capability sets to find binaries and services that hold more privilege than they need, then drop them — replacing blunt setuid-root with least-privilege capabilities.
-
Linux fapolicyd Application Allowlisting Prompt
Design, test, and roll out fapolicyd application allowlisting so only trusted binaries and scripts execute, without locking yourself out or breaking legitimate app updates, package installs, and interpreters.
-
Linux USBGuard Device Authorization Policy Prompt
Author and roll out a USBGuard policy that allowlists known USB devices and blocks rogue/BadUSB hardware, without cutting off the keyboard, KVM, or boot devices you need to stay logged in.
More Linux Admins prompts & error guides
Browse every Linux Admins prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.