Greg KH wrote: > On Fri, Oct 02, 2009 at 03:55:57PM +0100, David Vrabel wrote: >> Alan Stern wrote: >>> >>> There might be programs which really _do_ want to unbind other >>> programs, so ruling out that capability in the kernel is likely to be a >>> mistake. My preference is to let userspace sort this out. >> If we do want to allow this behaviour we certainly don't want user B >> able to disconnect the usbfs driver from a device in use by user A. > > Why not? How do we tell if a device is "in use"? An interface is in use if the process has claimed it. > What is the problem you are seeing here? The initial problem was that it isn't possible (with current libusb) to claim an interface that is unused by a user space program but is in use by a kernel driver (neither libusb_kernel_driver_active() or libusb_claim_interface() can distinguish between userspace and kernel users). This is solved by a simple libusb change. Allowing users to claim interfaces in use by other users has security implications. As a theoretical example consider some sort of wireless communication device where the user supplies a secret shared key to set up the encrypted link between two devices. Traffic over the USB bus is unencrypted. An attack might look something like this. 1. User A supplies the secret key to the device and the secure connection is established. 2. User B claims the device and can submit IN requests to intercept some of the the unencrypted traffic. User A is largely unaware of these as the missing data is indistinguishable from packets lost over the air. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
