USBGuard - what should we allow or disallow by default?

Development
41

The manpage man usbguard-rules.conf lists more rules and documentation then the USBGuard Rule Language on their webpage.

usbguard-rules.conf(5) — usbguard — Debian bookworm — Debian Manpages

1 Like
42

Some devices other than storage devices are allowed by the configuration as detailed above. In particular, keyboards and mice can be attached if no other USB keyboard or mouse is attached yet. Additionally, camera and audio devices are now allowed.

vim /usr/lib/systemd/system/usbguard.service shows that USBGuard is WantedBy=basic.target, which means it starts pretty early in the boot process (after the core system is operational but before users can log in and a graphical session appears). It might not finish initializing by the time login prompts appear and a GUI works, but it starts early.

Good to know, thank you!

1 Like
43

usbguard-notifier will be installed by default in Kicksecure 18 and above.

1 Like
44

lol no disrespect but you can also do sudo usbguard list-devices -v

45

So much intriguing lore in this discussion.

Here is my 2cents, I think bluetooth USB class should either be rejected altogether or a commented out line that rejects them should be there for common ground like other of the lines in configs related to bluetooth. Since kicksecure doesn’t disable bluetooth altogether it does have lines that do if you need to.

46

The Wireless Controller base class 0xE0 defines a small set of standard subclasses. 0x01 appears to almost always be bluetooth and 0x02 for USB devices that implement a (IEEE 802.11) WiFi radio interface. How would go about rejecting the 0x01 subclass while allowing the 0x02 subclass without outright rejecting the whole wireless controller class 0xe0 :thinking:

1 Like
47

Hey just checkin in here but I will give you the outputs of those commands after I reinstall Kicksecure and download the raw USBGuard configs. My wife has been in the hospital so my time has been spent elsewhere.

Hope recent developments are going well with USBGuard

48

Noted, I can test how true that statement is since I have a wireless wifi adapter, and old wireless Logitech mouse and a old TP-Link bluetooth adapter sitting around. When I say “old” I mean like bought new within the last 6 years so.

49

  • Should account user (in USER session) be able to use usbguard-notifier yes / no buttons?
    When a new USB device is attached, USBGuard Notifier shows a passive popup with yes / no buttons.

  • Behavior of the buttons:

    • Pressing no: nothing happens (default behavior)
    • Pressing yes: the USB device is allowed

  • Alternative policy option:
    It could be configured so that only the sysmaint account (in the SYSMAINT session) is allowed to authorize devices using the yes button.

  • Question about the threat model:
    What threat model are we actually trying to address with USBGuard?

  • Scenario 1: untrusted user with unlocked screen:
    Is someone physically present at the computer with an unlocked screen considered a threat? For example, in a corporate environment, an untrusted employee might insert a malicious USB device.

  • Scenario 2: trusted user with unlocked screen:
    Or is the assumption that if the screen is unlocked, the logged-in user is trusted and should be allowed to authorize new USB devices by clicking yes? This would align more with a personal computer context, where only trusted users can unlock the screen.

  • Main use case for USBGuard?
    Is the goal to have USBGuard protect the system only while the screen is locked, relying on users not to authorize unexpected USB devices when logged in?

Aaron: usbguard-notifier allows users to ad-hoc allow and deny USB devices when they are attached. Should we allow the qubes and sudo groups to have modify permissions in usbguard as well to allow this to work?

1 Like
Kicksecure 18 Released! Major Release Upgrade!
50

Slight correction, the buttons are labeled accept and reject, and clicking reject is not a no-op. When a device is denied access, it still is “seen” by USBGuard and the kernel, but it isn’t used. When a user clicks reject, the kernel actually disconnects the USB device (not sure if that’s a purely software thing or if it involves hardware also, but a message appears in dmesg stating USB disconnect, device number X upon pressing the reject button). In theory a fully rejected device might be less of a threat than a recognized but unauthorized device?

1 Like
51

Upon reflection, our current USBGuard already attempts to strike a balance, i.e. Kicksecure Stable Version User Experience / Reasonable Security.

  • Boot time devices allowed: Any devices attached before system boot are accepted.

This seems to be the most appropriate threat model.

USBGuard is already intrusive enough. Making it even more complicated by breaking the USBGuard-Notifier accept / reject buttons seems the wrong.

For this scenario, a custom USBGuard configuration and uninstallation USBGuard-Notifier might be appropriate. (sudo dummy-dependency usbguard-notifier)

52

Sorry to interrupt but is usbguard implemented in kicksecure if I do debian morphing for a template in Qubes OS?

It seems like I don’t have it. I checked the
dpkg -l | grep usbguard - nothing
systemctl status usbguard - not found
/etc/usbguard/ - non existen

I currently use debian 12 xfce template morphed to kicksecure for my sys-usb and I really like it

53

USBGuard is only going to be a feature in Kicksecure 18 and higher. Kicksecure 17 does not have it and it isn’t planned to be added to Kicksecure 17.

1 Like
54

Got it, thanks

55

Main use should be to mitigate possible Bad USB cables/peripherals which almost always have HID. The other use should be like redhat corporate where only trusted USB peripherals allowed. Just like a DoD skiff where a narrow, well monitored entry point for personnel and equipment, keeping the interior protected from anything that shouldn’t be there.

Also wanted to chime in about I think allowing only devices plugged in USB peripherals before starting the OS is enough I don’t think sudo should be granted to user to override this.

If a user needs to allow a device other then a mass storage they should 1. reboot with plugged in device or 2. use sysmaint to allow the USB device so that the system applies to the config to explicitly allow said device when they use “user” account.

The only hole in this is mass storage devices with infected or altered firmware. This isn’t a USBGuard issue though. This could be covered in another thread but two things come to mind The F3 (Fight Flash Fraud) Utility f3 that detects if drive really is the amount of space it claims (fake advertised storage devices sold on Amazon, Aliexpress, Etc.). The second is hdparm and smartctl which can I believe can SHA256 hash the firmware on a drive.

56

USBGuard-Notifier is great but I dont think user account should have ability to accept / reject in all do respect.

57

Also what happened to the config file in the security-misc repo and whats this change about “Split the security-misc into security-misc-shared”? I’m quite confused here can you explain the changes?

58

Some of the configuration in security-misc is only suitable for some installations for one reason or another (for instance MAC randomization is unsuitable for servers, see MAC randomization breaks root server and VirtualBox DHCP / IPv6PrivacyExtensions might be problematic · Issue #184 · Kicksecure/security-misc · GitHub). We split the security-misc package up into “shared”, “desktop”, and “server” packages so that we can add hardening config that is applicable to some scenarios while omitting it from others where it doesn’t work.

1 Like
59

What’s your threat model? Why should account user not have the ability to accept / reject?

60

Ok so here me out my threat model is a targeted attack via a Bad USB charging cable or USB type adapter that gets around the rules somehow. Since Kicksecure is one of the few projects that does ship USB guard that I know of next to Tails (Theirs only protects against Scenario 1), I feel woried an advanced adversary could target this towards Kicksecure (rejecting HID is honestly the strongest protection :+1: )

Scenario Targeted: user buys USB peripheral online (ie. charging cable, adapter, or mass storage). The USB is swapped with a malicious one in via mail tampering and is swapped for a BadUSB. The user then logs in as USER not SYSMAINT. They then precede to plug in USB device. Since user can now allow/deny, the device in theory could load code that auto allows since it now has sudo privlages via the change to allow sudo privalges to user for usbguard?

Is my understanding correct that Bad USB could therefore persist across reboots if the attacker manages to get the user to run the allow (whitelists device) command once via some BadUSB that get around the rules? Then user goes logs into SYSMAINT the root account with a now malicious USB whitelisted could do more damage?

potential for silent whitelisting?