KB888924: Difference between revisions
Save work for use later. |
Save contents. |
||
| Line 2: | Line 2: | ||
== Introduction == | == Introduction == | ||
This article documents the procedure to control USB activation policy in order to allow explicitly approved devices of certain class on systems running Linux. Unlike Microsoft Windows, the Linux kernel controls USB devices with an instance-based model only, so that blocking particular types of devices involve in blocking all devices from a certain USB controller. | This article documents the procedure to control USB activation policy in order to allow explicitly approved devices of certain class on systems running Linux. Unlike Microsoft Windows, the Linux kernel controls USB devices with an instance-based model only, so that blocking particular types of devices involve in blocking all devices from a certain USB controller. This results in additional supplementary software packages be installed in order to provide functionalities of managing devices/instances with a particular class, for example, class 03, to control on unauthorised USB HID devices in order to protect unauthorised gaining of the desktop/console. | ||
== Symptoms == | |||
Suppose that you have the following goals: | |||
# Forbid USB HID devices newly connected to the Linux system to function unless explicitly authorised, and | |||
# The policy should not cause any interferences on devices with other types, for example, mass storage devices or audio devices. | |||
Because Linux does not natively moderate USB instances based on device class, a one-rule-fits-all policy should be enforced instead. | |||
== Solution == | |||
To the best of the composer's knowledge there is no solution so far for this demand. | |||
In order to restrict new devices or instances of all types/classes, write the character "0" as the only character, in the file located at /sys/bus/usb/devices/''hub_name''/authorized_default, where "hub_name" is the name of the USB hub or root hub for which devices it connects to needs authorization. | |||
In case you need to authorise a USB HID device, first determine its class type and instance ID by running ''lsusb -t''. This populates all the USB devices in hierarchical listing, including the location of devices and their classes. Make sure that the device you're being authorized has class name "Human Interface Device". Record the instance location. | |||
In order to authorise a desired device, calculate the appropriate UNIX file location by concentrating the bus number, port number, device number and instance number (if any) together. For example, for a USB HID device connected to Bus 02, Port 1 and Device 1, which is a root hub, and the device has Dev number 2 which is the 1st device/instance located under the root hub (which has Dev number 1, 1+1=2 the second one to the root hierarchy of hub), its UNIX file name is "2-1:1.0". Find the appropariate file name, and in this example, the full path should be /sys/bus/usb/devices/2-1:1.0/. Place the number "1" and with only the charater in the file named "authorized". | |||
Other affected devices should also be found out and authorized, in order to mitigate this issue exists natively in Linux by design. | |||
An alternative solution is to install USBGuard, in this case the system administrator will get more precise design by using role-based access control. | |||
== Outcome == | |||
The system administrator should be able to control USB devices attached to systems running Linux, with the natively-supported functionality. | |||
Additionally, system administators should be able to use the third-party solution USBGuard if they have access to the installation resources, to make more precise and concrete controls on USB devices based on their device classes. | |||
__INDEX__ | __INDEX__ | ||
Latest revision as of 18:50, 7 October 2024
Introduction
This article documents the procedure to control USB activation policy in order to allow explicitly approved devices of certain class on systems running Linux. Unlike Microsoft Windows, the Linux kernel controls USB devices with an instance-based model only, so that blocking particular types of devices involve in blocking all devices from a certain USB controller. This results in additional supplementary software packages be installed in order to provide functionalities of managing devices/instances with a particular class, for example, class 03, to control on unauthorised USB HID devices in order to protect unauthorised gaining of the desktop/console.
Symptoms
Suppose that you have the following goals:
- Forbid USB HID devices newly connected to the Linux system to function unless explicitly authorised, and
- The policy should not cause any interferences on devices with other types, for example, mass storage devices or audio devices.
Because Linux does not natively moderate USB instances based on device class, a one-rule-fits-all policy should be enforced instead.
Solution
To the best of the composer's knowledge there is no solution so far for this demand.
In order to restrict new devices or instances of all types/classes, write the character "0" as the only character, in the file located at /sys/bus/usb/devices/hub_name/authorized_default, where "hub_name" is the name of the USB hub or root hub for which devices it connects to needs authorization.
In case you need to authorise a USB HID device, first determine its class type and instance ID by running lsusb -t. This populates all the USB devices in hierarchical listing, including the location of devices and their classes. Make sure that the device you're being authorized has class name "Human Interface Device". Record the instance location.
In order to authorise a desired device, calculate the appropriate UNIX file location by concentrating the bus number, port number, device number and instance number (if any) together. For example, for a USB HID device connected to Bus 02, Port 1 and Device 1, which is a root hub, and the device has Dev number 2 which is the 1st device/instance located under the root hub (which has Dev number 1, 1+1=2 the second one to the root hierarchy of hub), its UNIX file name is "2-1:1.0". Find the appropariate file name, and in this example, the full path should be /sys/bus/usb/devices/2-1:1.0/. Place the number "1" and with only the charater in the file named "authorized".
Other affected devices should also be found out and authorized, in order to mitigate this issue exists natively in Linux by design.
An alternative solution is to install USBGuard, in this case the system administrator will get more precise design by using role-based access control.
Outcome
The system administrator should be able to control USB devices attached to systems running Linux, with the natively-supported functionality.
Additionally, system administators should be able to use the third-party solution USBGuard if they have access to the installation resources, to make more precise and concrete controls on USB devices based on their device classes.