USB Guard | Depend on it and configure rules #166
Conversation
|
If we don't depend on the package, there is very little sense in having configuration files installed for it. So which is it going to be, are you planning to drop all the various dependencies? |
|
" The config files are good to have here. related: |
|
So @adrelanos what are waiting regarding this? |
This actually does something else as per documentation.
Best to copy this verbatim?
|
The rules aren't necessarily taken from a source. Some of them I wrote myself. It means: reject a device, that presents itself as a mass stroage device, and a CDC data device, at the same time. Class codes for different interfaces can be looked up easily here. |
|
Just a remark. I tried this rules for about 2 months now with various USB devices including hard drives, cameras, microphones and speakers and have not encountered any inconveniences yet. |
There was a problem hiding this comment.
Code is also found on the usbguard docs.
Reject devices with suspicious combination of interfaces
A USB flash disk which implements a keyboard or a network interface is very suspicious. The following set of rules forms a policy which allows USB flash disks and explicitly rejects devices with an additional and suspicious (as defined before) interface.
allow with-interface equals { 08:*:* }
reject with-interface all-of { 08:*:* 03:00:* }
reject with-interface all-of { 08:*:* 03:01:* }
reject with-interface all-of { 08:*:* e0:*:* }
reject with-interface all-of { 08:*:* 02:*:* }
The policy rejects all USB flash disk devices with an interface from the HID/Keyboard, Communications and Wireless classes. Please note that blacklisting is the wrong approach and you shouldn’t just blacklist a set of devices and allow the rest. The policy above assumes that blocking is the implicit default. Rejecting a set of devices considered as “bad” is a good approach how to limit the exposure of the OS to such devices as much as possible.
Seems ok to me. Will interfere with like single board computers, but as commented, for default config and average user, seems good.
Here are some slides from blackhat 14, that confirms that sus usb devices most likely contains multiples descriptors.
Exactly. This is where the core concept stems from as @adrelanos pointed it out before. I have made some more additions with more of the commonly used interfaces to the list to make it a little more extensive. Which is completely not necessary since they are normally blocked anyway unless we explicitly allow them in the rules. The original list itself is also completely superfluous. This is just a fallback in case the usbguard config is modified to allow by default. Let me fix that and make it more clear to avoid confusion. Actually let me update the rules to add some more little things from the usb guard documentation. Also, I will get rid of the combinations because it might introduce confusion, since no explicit rejecting is needed anyway, unless we change the configuration to allow by default, which we do not. I should have made this more clear in the beginning. |
We should depend on usbguard as a package. When installed on debian, usb guard settings are configured in a way that all devices are rejected, only those that were already plugged in before the daemon starts are allowed.
Normally this is not optimal. We should by default reject everything and only whitelist the devices that we know and trust. But this requires configuration at the user end. So for now, we better leave the debian config as is.
We also add new rules with our config file. These rules do not configure the daemon. They define how the daemon behaves when it is 'applying policy'. The policy is by default blocking everything. We slacken this by allowing devices with mass storage interface, so the users can plug in their external hard drives and usb's. Then we blacklist especially suspicuous storage devices. Those that try to also behave like a keyboard at the same time for example.
Normally this is also not optimal, but it is a big improvement. We don't allow anything else. That means everything else is implicitly blocked. If the user plugs in a keyboard or mouse or anything else, it will be blocked. If these devices are plugged in when the machine starts up, they are allowed. This should not be too inconvenient for the user, because most peripherals are almost always already plugged in when the machine starts up. If not, they can be manually allowed or the system can be rebooted for the device to be allowed after having booted.