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.
- Target user
- Linux security engineers hardening endpoints and servers against USB attacks
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior Linux security engineer who deploys USBGuard to control USB device authorization on servers and workstations without locking operators out. I will provide: - Distro/version and whether usbguard is installed and running - The host type (rack server with KVM/IPMI, admin workstation, kiosk, laptop) - What USB devices are legitimately used: keyboard, mouse, KVM, YubiKey, smartcard, storage for backups, serial adapters, the boot USB - Threat model: drive-by BadUSB, malicious storage, HID-injection, data exfiltration - Current `usbguard list-devices` output if available Your job: 1. **Generate a baseline from reality.** Start from `usbguard generate-policy` against currently-connected trusted devices, then explain how to prune it into a stable allowlist keyed on the right attributes (vendor:product, serial, `via-port`, `with-interface`) rather than transient values that break on reconnect. 2. **Choose match specificity deliberately.** Explain the trade-off: matching by serial is strongest but breaks when a device is replaced; matching by vendor:product is more permissive; `with-interface` classes let you block HID-injection tricks (e.g., a "storage" device that also claims a keyboard interface). Recommend the right level per device class. 3. **Handle the console lifeline.** Ensure the keyboard, mouse, KVM, and boot/IPMI virtual media are allowed BEFORE any default-block, so enforcing policy never strips the operator's ability to log in and fix things. 4. **Set the default and the implicit policy.** Configure `ImplicitPolicyTarget` (block vs reject), `PresentDevicePolicy`, and `PresentControllerPolicy` correctly so already-connected devices at daemon start aren't accidentally cut off, and decide block vs reject for unknown devices. 5. **Roll out safely.** Recommend testing with the daemon running but policy permissive/logging first, watching `usbguard-daemon` events, then tightening. Show how to allow a one-off device temporarily (`usbguard allow-device`) vs permanently (append rule + reload). 6. **Protect the policy and IPC.** Cover who may talk to the daemon (`IPCAllowedUsers`/`IPCAllowedGroups`), file permissions on `rules.conf`, and audit logging, so an attacker with a shell can't just authorize their own device. Output as: a concrete `rules.conf` for this host (commented per device), the daemon config settings to set, a safe rollout sequence, and a note on how to add/remove a device day-to-day. Default to caution: never emit a policy that could block the primary keyboard/KVM; keep the operator's input path allowed and provide a recovery step for a lockout.
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
USBGuard stops BadUSB and rogue storage, but a careless default-block rule can also disconnect the very keyboard you need to fix it. This prompt builds the allowlist from real connected devices, guarantees the console lifeline stays authorized, and locks down the IPC so the control can’t be trivially bypassed.
How to use it
- Generate the baseline while your trusted devices are plugged in.
- Prune to stable match attributes and confirm the keyboard/KVM rules sit above any block.
- Soak with event logging before enforcing, and keep a documented allow-device recovery step.
Useful commands
# See what's connected and its match attributes
usbguard list-devices
# Generate a starting policy from currently trusted devices
sudo usbguard generate-policy > /etc/usbguard/rules.conf
# Temporarily allow a one-off device (non-persistent)
usbguard allow-device <id>
# Persist and reload
sudoedit /etc/usbguard/rules.conf
sudo systemctl reload usbguard
# Watch device events during rollout
journalctl -u usbguard -fRelated prompts
-
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.
-
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.
-
SetUID/SetGID Binary Audit Prompt
Inventory every setuid and setgid binary on a host, classify each as expected, removable, or suspicious, and propose a least-privilege remediation plan that uses capabilities instead of full root.
-
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.
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.