What extra layers of protection should I add for better security on Qubes OS 4.3?

FranklyFlawless · March 9, 2026, 5:20am

I also forgot to mention about USBGuard, which is within dom0:

Currently the policy is permissive and has an open GitHub issue:

github.com/QubesOS/qubes-issues

Hardened option for single USB keyboard

opened 12:29PM - 02 Jan 24 UTC

emanruse

P: default C: input proxy

### The problem you're addressing (if any) Currently, on systems which can us…e only USB keyboards, it seems possible to have unrestricted number of such USB keyboards that are automatically allowed to connect to dom0 due to `/etc/qubes-rpc/policy/qubes.InputKeyboard` permissive policy. This makes it possible a malicious USB device (e.g. a USB memory stick) to represent itself as a keyboard, do its mischief, then switch back to being a non-keyboard. Using usbguard inside sys-usb to allow only specific predefined keyboards is a possibility, however it might result in a situation when the user gets locked out of the system. Example: The user has only one physical keyboard and whitelists it in usbguard rules. If the keyboard hardware stops functioning (e.g. the keyboard is physically damaged), the user will be compelled to replace it with another. However, since the new keyboard will not be whitelisted, the user won't be able to access the system through it, regardless of the fact that it is a good (non-malicious) device. ### The solution you'd like Provide an option (perhaps even enforced by default) which allows the user to restrict the number of possible USB keyboards on the system to 1 (one) at a time. ### The value to a user, and who that user might be The proposed solution would make it impossible for a malicious device to act as described, as a second keyboard will be denied. The only way to use another USB keyboard would be to physically disconnect the first one, then connect another. That must also be documented properly. #### Possible caveat **I don't know if that is possible** (there are [some](https://forums.tomshardware.com/threads/every-usb-port-will-randomly-disconnect-for-a-few-seconds-on-new-pc.3793952/) [reports](https://superuser.com/questions/1450976/external-usb-hard-drive-momentarily-disconnects-when-additional-external-hard-dr)), but just for extra consideration: If for some reason (e.g. a driver bug, power related issues or other) the malicious USB device is able to cause the original keyboard to (appear to) disconnect or simply "sneak in" while the original good keyboard is actually disconnected, the proposed solution will not work *per se* - the malicious device may still connect as a keyboard and accomplish the described attack, and during that period the actual keyboard will be blocked. To prevent such possibility, additional possible measures to the solution might be: - Enable any newly connected USB keyboard **only after reboot** In this way, even if a temporary disconnect happens, no other device would be able to take over a running the system, because to accomplish an attack the malicious device would have to cause a reboot of dom0 through sys-usb, which seems impossible in Qubes OS (at least not without a serious security bug). - UI for easy whitelisting of newly connected keyboards (using usbguard rules in sys-usb) Without other input device (e.g. at least a mouse able to click and confirm the newly connected keyboards), a possibility for user input might be the power button of the system. A service like `acpid` may be used to monitor for events. Example usage: A new keyboard is connected. The UI dialog shows up and asks for confirmation. The user is required to press the power button of the system to activate the new keyboard, after which it gets whitelisted in `/etc/usbguard/rules`. The `acpid` service may probably run in a separate VM (sys-acpi), thus making it impossible for a malicious device to attack both sys-usb and sys-acpi. Having sys-acpi may even provide extra security, e.g. the number of presses within a period of time might be configurable, e.g. "must press 3 times within 10 seconds", and may serve as a "password" for allowing new USB devices. **Additional notes**: As by default passwordless root is enabled in VMs, whitelisting devices in sys-usb itself may turn out vulnerable. I don't know what inter-VM communication mechanism for this may be suitable but it seems better to isolate the "credentials" of devices - have another VM store and verify if a device is whitelisted, then report the result back to sys-usb.