USB device authorization [LWN.net]

Universal serial bus (USB) devices do not normally have much of a security model associated with them. If a user is able to plug a USB device into the system, said system assumes that the device is properly authorized to be there. There are situations where the connection of USB device causes people to worry; the usual scenario is the fear of corporate secrets being copied into some sort of USB storage device and being carried out of the building. In general, in situations where such fears run strong, the response has involved (attempted) bans of USB devices or simply filling the USB ports of accessible computers with glue.

Wireless USB changes the situation slightly. This protocol allows USB devices to operate remotely, without that pesky cable to trip over; it can be thought of as occupying a niche similar to that of Bluetooth. While a typical laptop user might be expected to notice an attacker plugging a normal USB keyboard into their system, said attacker could attempt to connect a wireless USB keyboard without coming near. Clearly, some sort of security layer is required. The wireless USB specification has anticipated this need; it provides for a whole series of acronym-laden techniques for (1) ensuring that both hosts and devices authenticate themselves to each other, and (2) that wireless USB communications are sufficiently well encrypted that they cannot be eavesdropped upon.

Iñaky Perez-Gonzalez is working on wireless USB support for Linux. He has come to the conclusion that the grungy details of wireless USB authentication belong in user space; the kernel cannot, on its own, keep track of which devices are known to the system and are allowed to connect. It is, however, up to the kernel to implement the authorization part of the equation: a wireless USB device which is not authorized should not be able to perform any sort of exchange with the host system. Iñaky's response to the authorization problem is this set of patches to the USB subsystem.

These patches add three new flags to the usb_device structure: wusb, authorized, and authenticated. The first indicates that a device is wireless, and the last (which is not yet used) indicates that the device has passed authentication. In the middle is the authorized flag which indicates whether it is OK to talk to the device. If the device is not authorized, the kernel will not even read its configuration to find the endpoints it provides; the only thing that can happen at that point is authentication. To that end, various points in the USB stack are changed to check the authorized flag before allowing access to a USB device.

User space is brought into the picture by way of the usual device-attach announcement and the creation of an associated sysfs tree. The sysfs directories for USB devices gain a new authorized attribute which corresponds to the internal flag; user space can enable access to the device by writing a non-zero value to that attribute. That infrastructure is all that is required for some sort of user-space daemon to notice the arrival of a new wireless USB device, check its database of known devices, possibly pop up some sort of pairing dialog to the user, and implement a decision on whether the device should be allowed to connect or not.

Iñaky has taken things a step further by realizing that this authorization mechanism need not be limited to wireless devices; it can, in fact, be used to allow some sort of management code to pass judgment on any USB device. There is a set of per-host authorized_default flags which can be configured by the administrator; simply setting the default to zero with no other action will disallow the connection of any new devices, whether wired or not.

A more complex implementation might allow only certain types of devices to connect. Keyboards and mice might be acceptable, but anything which could remove data from a system - storage devices or printers, say - would be disallowed. Or storage devices could be allowed, but only if they contain some sort of properly signed authorization certificate which can be verified by the host system. There are a number of interesting possibilities. The resulting security will be less than that which could be had by filling in the ports or simply configuring USB out of the system entirely, but it might be just what is needed at some sites.

Overall, it's a relatively simple patch set which adds some interesting capabilities. Much of the hard work - authentication and encryption setup - remains, but that's a job for user space. Iñaky has asked that this code be merged for 2.6.23; it's just a bit late, though, for a relatively untested (in the wider world) chunk of code to slip through the merge window. 2.6.24 seems more likely.

(Log in to post comments)