Bug 454479

Summary: USBGuard integration
Product: [Applications] systemsettings Reporter: dauntless <60f31543-f82f-492a-8430-25db5521568b>
Component: kcm_deviceautomounterAssignee: Torrie Fischer <tdfischer>
Status: CONFIRMED ---    
Severity: wishlist CC: gauvain, nate, plasma-bugs
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Other   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description dauntless 2022-05-27 10:49:27 UTC
SUMMARY
GNOME has a USBGuard integration (https://wiki.archlinux.org/title/USBGuard#GNOME_integration) that gives protection against physical attacks like Evil Maid. It would be great to see KDE have parity here.
Comment 1 Nate Graham 2022-05-27 14:17:03 UTC
What kind of integration are you wanting, specifically? What does thew GNOME integration look like?
Comment 2 dauntless 2022-05-27 15:03:20 UTC
I've only used the CLI version so am not sure how GNOME's version works other than it's description. For an easy-to-use GUI integration for KDE however it'd be great if it had the following features:
- A System Settings>Hardware>Removable Devices submenu for USBGuard configuration
- A button to enable USBGuard and generate a ruleset based on the currently attached USB devices (equivalent to `usbguard generate-policy > /etc/usbguard/rules.conf`)
- `usbguard-daemon.conf` converted to radio buttons/dropdown menus and other buttons to easily edit that file
- `usbguard-rules.conf` also converted to various buttons to make editing it easier
- Desktop notification whenever a USB device gets attached, saying that it either did allow/block/reject the device based on USBGuard rules
Comment 3 Nate Graham 2022-06-01 15:59:21 UTC
Thanks. Looks like we have an opportunity to leapfrog GNOME here, as their support appears to be quite rudimentary.
Comment 4 Gauvain Roussel-Tarbouriech 2025-01-07 15:10:04 UTC
To add on the previous comments, GNOME currently has a toggle in their system settings allowing to block any newly connected USB device when the lock screen is active on top of a few other hidden dconf behaviors, as usual with them.

I believe the lock screen behavior is of particular interest (maybe enough to even ship it enabled by default?) as it's low maintenance and high impact:

* It protects against evil maids, obviously.
* It also protects against law enforcement (or similar) agencies keeping devices indefinitely powered on until they find a kernel exploit to break in, such as iPhones with Graykeys.