-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Aug 23, 2025 at 09:43:20PM -0500, Aaron Rainbolt wrote: > In Kicksecure 18 and higher, we're going to be shipping USBGuard, > enabled by default, with a configuration that allows all devices that > are present in the system on bootup, and blocks all non-whitelisted > devices that are plugged in after bootup. By default, the whitelist in > Kicksecure will allow USB mass storage devices, and will allow a single > mouse and keyboard at a time (additional keyboards are rejected).
This "single mouse/keyboard" part may be problematic in practice. First of all, many keyboards have multiple HID interfaces (for example many or even most I've seen have one for standard keys and another one for multimedia keys). But even if you consider just whole devices, not individual interfaces, many devices have a HID interface in additional to its main function. Some examples I've seen include a USB headset (keys were for volume + mute buttons) or a camera (there was a physical button on it, not sure what its function was). That said, I expect people relying on USB keyboard/mouse have them plugged in on boot, so those should be allowed by the "present on boot" rules. > All > other devices are rejected, including devices that combine a USB mass > storage interface with anything else, and devices that combine a > keyboard or mouse interface with anything (except for "unified" > keyboard/mouse devices like are common with some wireless receivers). > The goal is to allow a limited subset of common USB devices to work out > of the box, while also thwarting devices like the USB "rubber ducky". Rejecting input devices is slightly less important in sys-usb than in the native case, because of the sandboxing in sys-usb (you don't instantly get control over the whole system). With https://github.com/QubesOS/qubes-issues/issues/3604 implemented, it would be even better, as you can select which devices to allow. > This feature set makes good sense for Kicksecure on the desktop, but > we're unsure if it makes sense in Qubes OS, if a user chooses to use > Kicksecure on sys-usb. On the one hand, USBGuard in sys-usb could > substantially increase the security of users who have to pass through > USB keyboards and mice to dom0 (only one keyboard and mouse would be > allowed, a keystroke injection device would be rejected so long as it > was not present when sys-usb booted and a legitimate USB keyboard was > already plugged in). Yes, if user uses USB keyboard, it's probably already plugged in on boot, but if they don't - likely the qrexec policy for input proxy is also left with default deny, so plugging "the first" (potentially malicious) keyboard later would be rejected too - just in a different place. > On the other hand, USBGuard could frustrate users > who need to work with things such as USB headsets, webcams, > touchscreens, and other "advanced" devices. In theory a user could > reboot sys-usb to get these devices to work (assuming our configuration > actually does trust everything present on bootup), but maybe that's too > much hassle? Yes, that may be a problem indeed. Ideally, I'd like sys-usb to work only as a multiplexer, and all the actual drivers to be running in other VMs, with devices connected via qvm-usb. But it isn't practical for several reason (compatibility with some devices, reliability, resources etc). In practice, we currently have several types of devices that are handled in sys-usb in recommended setup: - - camera (+ qubes-video-companion) - - HID (+ input proxy), ideally with https://github.com/QubesOS/qubes-issues/issues/3604 implemented - - storage (+ qvm-block) - - sometimes audio (as in, nominate sys-usb to be "audiovm", many audio devices are unreliable with qvm-usb...) - - sometimes android (many people report it not working with qvm-usb) The last two I'd very much like to avoid, especially since "audio" sometimes really mean "bluetooth + audio". But unfortunately compatibility here is a problem... FWIW, qvm-usb should work just fine with devices denied by USBGuard (it has a special handling for it). > The USBGuard configuration we intend to ship in Kicksecure 18 can be > seen at [1]. > > Would enabling USBGuard in Kicksecure's Qubes OS templates make sense, > or would this cause too many problems for users? In qubes you can easily make it opt-in/opt-out via qvm-service. > If it should be > included, does our default configuration make sense, or is it too > restrictive? (On the topic of whether or not the existing configuration > is too restrictive, I made a post on the Kicksecure forums asking for > feedback at [2].) See the list above as for the config suggestion. I think in practice most would be handled by the "present on boot" rule anyway, but possibly not all - especially audio/video devices may be plugged in later. This may even include some built-in laptop cameras - some laptops with hw switches for camera not only cover their lenses, but actually disconnect the device (this is the case for example on Novacustom laptops). > [1] > https://github.com/Kicksecure/security-misc/blob/master/etc/usbguard/rules.d/30_security-misc.conf > [2] > https://forums.kicksecure.com/t/usbguard-what-should-we-allow-or-disallow-by-default/1248 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmirMxkACgkQ24/THMrX 1yyz6wf6AxQPYmOmMxzr3BjwIkln+OmJAN2fxTxLevMxQPXVOQxEtfnLDUGlFndM nU3DJBilM1kjG67aitaYIt5bUQc/BlBh9LfDDwOsbd5q+OGglzjZHpg8r9FnR7YC mZkRr9kAZhf29QjPo60AbtgAQvgNBJVlsrPqUJbLX9Yrjhgocs7nBMoALSH+zsX6 FnP/XRcoiUoi7xddGLHzCamDiEwTCemxTvwnyW75tMV2Ws/1gjdf1j0p4hiRMgLv tIXkbYYeWZfEN7XyQqCm4c5s4DSsT/5BQPJJon7yJ3tNpLhQa0tj6RFxU1Cy0va9 5vGXs6so7Oh6paAQtVplpAfW4vYlGg== =+2Ez -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/qubes-devel/aKszGcR37tFxZBuB%40mail-itl.
