How can I order USBGuard to don’t reject my Yubikey or any other device?
I’ve installed usbguard-notifier, when I connect my yubikey I select to allow it, but it ignore me xd.
I can’t use the yubikey unless pluged in in the boot, but even then if i disconnect it and reconnect, usbguard reject it continously.
Any way to resolve that?
That’s weird, it shouldn’t do that. If you run groups in a terminal, does your account show up in the sudo group? If so, can you boot into sysmaint mode and see if /etc/usbguard/IPCAccessControl.d/:sudo contains the string Devices=listen,list,modify? If the answer to either of these questions is “no”, that’s why you aren’t able to tell USBGuard to allow your Yubikey.
The intended way to work around the USBGuard limitations in a secure way is to use the notifier popups, or to plug the device in before boot. It’s probably better to figure out why the popups aren’t working as expected before trying to change the settings to allow the device to be accepted automatically.
If you do want to try to configure USBGuard to allow your device automatically, you’ll probably want to modify its configuration by writing a file at /etc/usbguard/rules.d/50-user.conf. For details about USBGuard’s rules language, see:
I am not using sysmaint split. In groups I have sudo and in the /etc/usbguard/IPCAccessControl.d/:sudo I have the following.
sudo cat /etc/usbguard/IPCAccessControl.d/:sudo
Devices=listen,list,modify
The only issue I can see if that in terminal I need sudo authentication for run the command. And maybe the popup isn’t running correctly because my user doesn’t have the necessary permissions.
There is any way to watch logs or execute the “Allow” command from CMD, maybe there I can get some feedback about why the Notifier isn’t working.
Can you do the following:
journalctl --user --boot -u usbguard-notifier.serviceThat will show the notifier’s logs, so we can see why the button isn’t working.
Starting usbguard-notifier.service - USBGuard Notifier...
Started usbguard-notifier.service - USBGuard Notifier.
Connection has been established
IPC call failed while trying to apply device policy 'allow' over device with ID xxxx with message:
Device lookup: device id: id doesn't exist
IPC call failed while trying to apply device policy 'allow' over device with ID xxxxx with message:
Device lookup: device id: id doesn't exist
Is like it doesn’t identify the device immediately after connecting it. I get the same error whether I accept or reject it.
Very odd. Do you have any other rejected-by-default devices (perhaps a second USB mouse or keyboard, or a MIDI interface) that you can test with? On my end, I’ve been able to accept additional USB input devices, a Yubikey Security Key (slightly different from a usual Yubikey), and a Midisport device, so I’m wondering if this is machine-specific or device-specific.
I’ve found the probably cause of the issue.
I’ve tested other USBs, Wi-Fi adapters and the notifier is working well. In the first instance the device is blocked but I can allow it and is added correctly to the devices-list.
What I have detected with my yubikey is the following:
The rule number 22 of the rules.conf is rejecting the interface. Unlike the other devices, it is directly rejected and removed from the devices-list, for this reason I can’t see it after connecting it.
## Explicitly reject any device with a mouse/keyboard interface in
## combination with some other interface.
## Mice and keyboards should likely never have non-HID interfaces provided
## alongside them.
22: reject with-interface all-of { 03:: 0b:: }
This is what I suppose is removing the device before the notifier appear. But the other error I see in the logs is that the ID that appear in the journal isn’t the same of the ID I see when executing usbguard watch. One ID is counter that increase by 1 (40,41,42) while I connect and disconnect different devices. But the ID I see in the logs is totally difference, I don’t know from where the notifier could be taking it.
The most viable solutions I see is to add the allow string with the hash and all I see from the watch command, to the rules.conf. Or just add the device with the id usbguard allow-device -p 1050:0407
reject id <VENDOR_ID>:<PRODUCT_ID> \
serial "<SERIAL>" \
name "<DEVICE_NAME>" \
hash "<HASH>" \
parent-hash "<PARENT_HASH>" \
with-interface { <CLASS_1>:<SUBCLASS_1>:<PROTOCOL_1> \
<CLASS_2>:<SUBCLASS_2>:<PROTOCOL_2> } \
with-connect-type "hotplug"
OK, that makes sense. I don’t have a “real” Yubikey handy, but I might get one at some point in the future. In the mean time, if you can give exact commands or configuration that lets you explicitly allow-list a specific device, we might be able to add that to our documentation.
Okey I’ve tried and this is working. But I don’t know which configuration is more secure, decide your self.
Sudo is required
Run usbguard watch in a terminal and plug-in the Yubikey.
After that, the policies and rules applied to the device will be printed, if it’s allowed, blocked or rejected. Something like that:
[device] PresenceChanged: id=xx
event=Insert
target=block
device_rule=block id 1050:0407 serial "" name "YubiKey OTP+FIDO+CCID" hash "xxxxx" parent-hash "xxxxx" via-port "xxx" with-interface { 03:01:01 03:00:00 0b:00:00 } with-connect-type "hotplug"
Copying all the text after device_rule= and changing the block/reject of the beginning with “allow” will be enough.
Add it to the /etc/usbguard/rules.conf
Example:
echo 'allow id 1050:0407 serial "" name "YubiKey OTP+FIDO+CCID" hash "xxxxx" parent-hash "xxxxx" via-port "xxx" with-interface { 03:01:01 03:00:00 0b:00:00 } with-connect-type "hotplug"
What I’ve realized is that just adding allow id 1050:0407 replacing the ID with yours, is enough.
So the following fields are optional, while more fields you add, the more accurate you are, the safer it is.