Require approval for new USB devices by default

[acrogenesis]

Unknown USB accessories can reach matching kernel drivers as soon as they are connected. A malicious gadget can spoof a supported device identity and reach a vulnerable driver, as in the public Pegasus USB Ethernet report.

This enables USBGuard authorization by default for fresh installs and existing installations through a migration. Devices connected during enrollment are trusted. Deferred installs leave USBGuard disabled until owner provisioning finishes, then enroll the owner’s connected hardware before enabling enforcement. New devices remain blocked until the user chooses Allow once, Always allow this device, or Keep blocked from a persistent notification. Remove > Security > USB Device Authorization disables protection; re-enabling preserves the saved policy.

Authorization and notification behavior

• Device descriptors remain data in private JSON requests. Only an opaque token crosses the terminal launcher. Approval rechecks the exact device after the dialog and targets its complete USBGuard rule, preventing a recycled numeric ID from authorizing a replacement device. It verifies the resulting allowed state and, for permanent approval, a matching policy rule before reporting success or consuming the request. Failed verification retains the request.
• Notifications use the final policy result. Trusted reconnects do not produce false blocked warnings. Every daemon connection scans blocked devices, restoring prompts when a restart revokes temporary approval.
• Delivery waits for the desktop notification service and retries failed sends automatically while rechecking the blocked device. One failed request does not abort the remaining scan; concurrent events deduplicate pending requests.
• Successful enrollment with no USB hardware stores an initialized comment-only policy. Enumeration failures still abort setup, and re-enabling does not silently enroll newly attached devices.

Optional boot protection

The default policy starts with USBGuard. Setup > Security > USB at Boot additionally captures currently connected devices into the trusted policy and applies usbcore.authorized_default=0 to current and Limine snapshot boot entries. The helper verifies effective command lines, image hashes, and embedded UKI command lines. It updates snapshot manifests and recovery copies under Limine's shared lock so later synchronization preserves the selected policy. Removal verifies permissive boot entries before full protection can be disabled; boot-only removal keeps USBGuard running.

Boot protection requires disk unlock and recovery without any USB devices. Even trusted USB input is unavailable at an encrypted-disk prompt before USBGuard starts. Older snapshots predating USBGuard keep all USB disabled after startup, including keyboards, networking, and storage. The confirmation, command help, and manual disclose this limitation. Trusting current devices does not make them available in those old roots.

This is defense in depth. An approved device can still reach its driver, and device descriptors are forgeable. The Pegasus driver fix remains an upstream kernel responsibility.

Validation

Focused USB regressions and the CLI suite pass. Coverage includes enrollment and enumeration failures, policy preservation, notification readiness and retries across multiple devices, reconnect scans, identity changes during review, and boot-policy regeneration. Bash syntax and whitespace checks pass.

Live Omarchy Lab checks:

• Trusted tablet reconnects produce no false warnings. A blocked mouse approved once receives a fresh prompt after a USBGuard restart.
• With the notification shell stopped, two blocked devices waited. Restoring the shell produced both prompts without another device event or watcher restart. Both visible alerts were inspected.
• Actual USBGuard policy generation with an empty USB sysfs view in a private mount namespace succeeds with zero bytes; the helper persists the initialized empty policy.
• Snapshot protection survives standalone synchronization. Disable followed by synchronization keeps both historical and newly created snapshot entries permissive.
• The updated boot confirmation was inspected at 1280×800 and canceled without changing boot policy.

Earlier Lab boot/lock validation: insertion while locked remained unauthorized with no interface or block device. Normal boot exposed the expected gap before USBGuard starts. With boot protection enabled, an enrolled QEMU tablet remained unauthorized until USBGuard matched it, then appeared as a working HID mouse. An untrusted storage device stayed unauthorized. Enable/disable and policy preservation were exercised through the shipped commands. Booting into a legacy snapshot without USBGuard was not tested; its limitation was confirmed from the policy path and a safe fixture.

Earlier Astra review identified the legacy-snapshot disclosure gap, now covered in the confirmation/help/manual. Subsequent review found the deferred-owner enrollment and false-success approval issues addressed by this revision. These fixes have focused automated and live Lab validation; a new full independent Astra review has not been run.

Latest review fixes: 67d173c9 defers enrollment and enforcement until owner provisioning finishes; 58a9c95b verifies device and policy state after approval. In Lab, a newly attached owner keyboard worked before enforcement, stayed allowed after enrollment and daemon restart, and a later untrusted mouse was blocked. With deliberately conflicting policy rules, real USBGuard returned success without allowing the mouse; the updated graphical dialog reported failure and retained the request. After removing the conflict, retrying that request succeeded, saved the policy, and survived a daemon restart. The full OEM ISO provisioning flow was not rerun; its setup leaf and owner-enrollment helper were exercised directly. Focused USB, CLI, provisioning groups/user, syntax, and whitespace checks pass. Lab’s original trust policy was restored and all temporary devices removed.

Earlier focused menu, config, systemd, provisioning, and unit-file verification checks also passed. The earlier aggregate shell run had unrelated baseline and host temporary-storage failures; it is not claimed as a clean full-suite pass.

Screenshots

Unknown device blocked

Review and authorization choices

Manual boot-time menu entry

Original USB at Boot confirmation

Updated USB at Boot confirmation, including legacy-snapshot recovery limits