max / alloy

Say that stopping usbguard leaves the bus refusing new devices Measured on fw12 by starting and stopping the daemon and reading the four root hubs against fw13, which has never run one. authorized_default is left at 0 on every hub, because RestoreControllerDeviceState=false is the shipped default and the unit has no ExecStop. Devices already attached keep the authorization they had, so nothing looks wrong until the next thing is plugged in and comes up unauthorized on a machine whose daemon is no longer running to explain it. Same mechanism alloy-usb-gate was already built around, confirmed here from the daemon's own lifecycle rather than from the gate's behaviour.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WFBzMprSmNCfvdj2cGZyka

Author: Max Johnson <me@maxj.phd> · 2026-09-08 19:09 UTC

Signed with PGP, not checked

Commit: 05d3a288fdf1d16410d76dc5ffc917aed092f3b5

Parent: 2bc39a0

1 file changed, +2 insertions, -0 deletions

M docs/STACK.md +2

			@@ -469,6 +469,8 @@
469	469
470	470		Arming survives an update, and that is now measured rather than assumed. `rules.conf` lives in `/etc`, which is the merged directory rather than part of the image, and seeding it with `usbguard generate-policy` immediately made `ostree admin config-diff` report `M usbguard/rules.conf`. That entry is the mechanism: a file ostree tracks as locally modified is carried into the next deployment, so a policy written on one boot is the policy the machine arms with after `bootc upgrade`. A policy that silently vanished on update would have been worse than none, which is why this was answered before the preset line was allowed anywhere near the image.
471	471
	472	+	Stopping the daemon does not put the bus back, and that is a trap for anyone arming by hand. `systemctl stop usbguard` leaves `authorized_default` at `0` on every root hub, because `RestoreControllerDeviceState=false` is the shipped default and the unit has no `ExecStop`. Devices already attached keep the authorization they had, so nothing appears wrong; the next device plugged in comes up unauthorized, on a machine whose daemon is no longer running to explain why. Measured on fw12 by starting and stopping the daemon and reading the four hubs against fw13, which has never run one and reads `1` on all eight. This is the same mechanism `usr/bin/alloy-usb-gate` was already built around, confirmed here from the daemon's own lifecycle rather than from the gate's behaviour: opening the gate is stop, then authorize every device, then set `authorized_default`, and a hand-run disarm has to do the last step too. It is runtime state, so a reboot clears it; the machine in front of you does not.
	473	+
472	474		Rejected: shipping the package on `client` only. A server-profile machine has a USB bus, and the ruling gives that profile the stricter half of the policy precisely because it has no keyboard to lock out and its recovery path is a provider console. It needs this more than a laptop does, not less.
473	475
474	476		Rejected: enabling the unit now and writing the policy later. It is one line and it would work on the bench for as long as the bench machine has a PS/2 keyboard, then take out the first machine that does not. There is no partial credit available here: an image that boots armed with an empty policy is worse than one with no usbguard at all, because the second is merely unprotected and the first is bricked.