USBGuard in Kicksecure-based sys-usb?

[Aaron Rainbolt]

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). 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".

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). 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?

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? 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].)

[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

[Demi Marie Obenour]

My personal setup is:

- sys-usb has usbcore.authorized_default=0 and USBGuard is set to only
allow my YubiKey and the internal camera. The USBGuard configuration
includes the port number, so USB devices plugged into other ports
can't impersonate devices I have chosen to trust.

- All other VMs allow all USB devices, but have none assigned by default.

- The firmware USB stack is disabled via a Dasharo feature.

Generally, I recommend using USB device assignment rather than handling
devices in sys-usb directly. The only exception is devices (like the
aforementioned camera and YubiKey) which are known to be trusted.
--
Sincerely,
Demi Marie Obenour (she/her/hers)

[Marek Marczykowski-Górecki]

-----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-----

[qubist]

Please see also:

https://github.com/QubesOS/qubes-issues/issues/8820

[Aaron Rainbolt]

On Sun, 24 Aug 2025 17:43:21 +0200
Marek Marczykowski-Górecki <marm...@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?

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.