On Fri, Oct 02, 2009 at 04:50:42PM +0100, David Vrabel wrote: > 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 happens if a process goes away? From the kernel side, we don't know if it really is still "in use" right? > > 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. The permissions on the usb devices through usbfs should handle this type of problem, like Alan pointed out. > 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. Wait right there. The admin set up the box so that both User A and User B had access to the device, so you are screwed. Don't do that :) Using PolicyKit, you can easily set this up so it will not happen, no kernel changes needed at all. > User A is largely unaware of these as the missing data is > indistinguishable from packets lost over the air. Yup, and they can blame their admin for setting up such a stupid situation :) thanks, greg k-h -- 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
