Authorize USB hubs and Human Interface Devices in USBGuard daemon

[adelton]

Description:

• Authorize USB hubs and Human Interface Devices in USBGuard daemon

Rationale:

• Without allowing hubs, it might not be possible to use any USB devices on the system.
• Without allowing Human Interface Devices, it might not be possible to interact with the system.

[jan-cerny]

@radosroka @tammar96 How do you like this patch? Should you have any feedback please submit a comment.

[radosroka]

Hey, there are several things I would like to point out.

• "equals" keyword has an alias which is called "all-of"
• the following rules won't match regular HID device like mouse or keyboard

allow with-interface equals { 03:*:* 03:*:* }
allow with-interface equals { 03:*:* }

We need to create a rule for keyboard that has following interfaces:

{ 03:00:01 03:00:02 03:00:03 }
or
{ 03:00:01 03:00:02 03:00:03 03:00:04 }
but not
{ 03:00:01 01:00:06 }

I'm not familiar with any possible way how to create rule like that. I'm pretty sure that it is NOT possible. It is very likely that we need to create some new extra keyword for such use case like "match-all". It can easily test mask like "03::" on each interface instead of using "equals" or any existing keyword/operator -> it is not implemented.

The same problem is with USB hubs I guess.

Another problem I've encountered is that I can have these two exact rules in rules.conf but this regexp check will not honor them and it will add generic rules to the end of the file. The same problem will occur with bus again:

allow id 2516:0047 serial "" name "MasterKeys Pro L White" via-port "3-3" with-interface { 03:01:01 03:00:00 03:00:00 
allow id 1038:1702 serial "" name "SteelSeries Rival 100 Gaming Mouse" via-port "5-4" with-interface { 03:00:00 03:01:02 }

Anyway, I don't like the idea that we are going to force customer/user to have such rule in rules.conf "to be compliant". If we do not want to get user into position that he's basically locked out from his computer after scan we should probably check daemon.conf for:

PresentControllerPolicy=allow
PresentDevicePolicy=allow
InsertedDevicePolicy=apply-policy

And add some note that user have to create or generate his policy with "usbguard generate-policy" and then change "PresentDevicePolicy" and "PresentControllerPolicy" to "apply-policy" after scan...

The second way how to avoid that undesired situation can be checking whether rules.conf is empty. That usually implicates not configured USBGuard therefore we can generate new policy via "usbguard generate-policy" that creates a new allow policy for each connected device.

https://usbguard.github.io/documentation/rule-language.html
https://usbguard.github.io/documentation/configuration.html

[adelton]

Anyway, I don't like the idea that we are going to force customer/user to have such rule in rules.conf "to be compliant".

I don't think we add these rules to be compliant. We add the rules to avoid locking the user out of the system when we enable usbguard.service. We might not catch all situations, like keyboards that have three or more 03:*:* interfaces. I guess the goal here is to allow at least something to work.

@stevegrubb, do I interpret the intentions of these rules correctly?

[stevegrubb]

The rule that is in the kickstart file was given to me by Daniel Kopecek. The intention is to allow: hubs, keyboards, and mice. That's all. Everything else needs to be blocked by default. This is needed because people need to get into the system via the console during emergencies. If the rule needs to be changed to make it correct, that's fine with me. Just let me know what the changes are so I can update the kickstart file.

[jan-cerny]

I don't think we add these rules to be compliant. We add the rules to avoid locking the user out of the system when we enable usbguard.service.

How can an user/customer know that? If he sees that it is a part of the profile he will think it is required to pass the rule to be compliant. I think adding a warning box and describing it in the rule description is needed.

Would it make sense to change this rule in a way that it would check whether the policy is non-empty and the Bash remediation would only generate the policy?

Just let me know what the changes are so I can update the kickstart file.

Could the kickstart run usbguard generate-policy? If yes, can we assume users will have the mouse and keyboard connected during system installation?

[yuumasato]

We add the rules to avoid locking the user out of the system when we enable usbguard.service.

These usbguard rules seem more like support for rule that enables usbguard service. Maybe these "basic" usbguard rules should be part of remediation for service_usbguard_enabled.

can we assume users will have the mouse and keyboard connected during system installation?

No, the system should be able to be installed automatically/remotely, and yet, be able to accept a mouse/keyboard for emergencies.

[yuumasato]

@radosroka @tammar96 Do you know if the usbguard rules as proposed in the PR cover commom keyboards and mouses?

As intention of the rule is not to block/allow a specific device, allowing easy to find mouse/keyboard should be enough.

[stevegrubb]

Mouse and keyboard may not be installed at system boot, but connected as needed. Also, don't forget, the purpose of the rules are not so much keep from locking out users, its to block malicious devices such as ethernet, bluetooth, mass storage, etc. By allowing mice, keyboards, and hubs, then the admin can go back in and open the policy if needed. But we do not want allow drive-by plugin in of malicious devices.

[yuumasato]

Can you add a warning that this rule doesn't aim to cover all possible types of keyboards/mice?

[adelton]

Rebased on master -> 6d99320.

[dahaic]

Just for posterity, and to unblock this. We will merge this PR as it is right now. That means the rule will have only limited usefulness outside of certification checkbox (as specific hardware will be needed to access hardened machine).

And when USBGuard gains capability to allow any combination of 03 and 09, we will remake the rule to make it generally useful and nice.

@radosroka ^^ :)

[radosroka]

Just for posterity, and to unblock this. We will merge this PR as it is right now. That means the rule will have only limited usefulness outside of certification checkbox (as specific hardware will be needed to access hardened machine).

And when USBGuard gains capability to allow any combination of 03 and 09, we will remake the rule to make it generally useful and nice.

@radosroka ^^ :)

OK, makes sense.

[yuumasato]

Thanks @dahaic, @radosroka and @adelton

[dahaic]

Feature request on the USBGuard side: USBGuard/usbguard#207