On Sun, 24 Aug 2025 17:43:21 +0200 Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> wrote:
> -----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). This is rather surprising to me, I don't understand why a keyboard wouldn't be able to supply both "normal" and multimedia keys via a single HID "device". My Logitech MX Mechanical Mini for instance came with a Logitech Bolt receiver, which presents itself as a keyboard, a mouse, and a couple of "unknown" devices which I would guess are for the weird features lots of Logitech devices have, that's it. The unknown devices are rejected, then the mouse and keyboard are allowed because the combo of mouse + keyboard on the same HID device is allowed, and thus the keyboard works even if plugged in after USBGuard is started. The keyboard has plenty of multimedia keys which seem to work fine (unless that's one of the "unknown" devices, I haven't tested the multimedia keys on a system with USBGuard.) > 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. Is this the case even if you enable the "not recommended" features that automatically pass through USB keyboards and mice to dom0 during installation? > > 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) HID and storage are already handled, I think enabling cameras, microphones, and audio devices by default should be pretty safe (they could only pose a threat if they attacked the respective parts of the kernel, and I don't expect the video and audio pathways to be too full of surprises except inasmuch as codecs are involved, if they are involved on the kernel level at all.) Android connectivity is one that worries me. I don't know how much attack surface MTP provides, and tethering likely provides fatal vulnerabilities if RNDIS is used, if Greg Kroah-Hartman's attempts to disable RNDIS in the kernel by default is any indicator. sys-usb limits the impact of such attacks, but a successful sys-usb compromise theoretically allows keystroke logging if the user uses a USB keyboard, so it's not great. If MTP is simple enough and doesn't have dangerous features, I could see this being OK to enable by default. > 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. Good idea. > > 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). Good point. Then I guess assuming no one else raises objections, I'll probably submit some config changes to enable cameras and microphones by default. I'll do some more research into MTP too, if I can find the time. > > [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/20250825214617.343e005c%40kf-m2g5.
pgpb2ufEJ2B3t.pgp
Description: OpenPGP digital signature
