Re: RFC/patch 1/6: wusb: add authorization control for devices
David Brownell <[email protected]>
| Newsgroups | gmane.linux.usb.devel |
|---|---|
| Message-ID | <[email protected]> |
On Wednesday 25 April 2007, Inaky Perez-Gonzalez wrote: > On Tuesday 24 April 2007, David Brownell wrote: > > On Tuesday 24 April 2007, Inaky Perez-Gonzalez wrote: > > > This patch introduces 'struct usb_device'->authorized. Devices with > > > that bit set can be used in the system (drivers are allow to > > > attach). Devices that don't will have the usb_probe routine aborting > > > driver binding. > > > > > > This is needed for WUSB devices: until we don't do the crypto > > > handshake, we can't allow the device to be used -- but in the > > > meantime, we need to be able to talk to it's default endpoint. > > > > How would this be different from testing whether > > > > udev->state == USB_STATE_UNAUTHENTICATED > > > > Other than "authenticated" != "authorized" ... as in, WUSB talks > > about the not-authenticated state, but a "not authorized" notion > > exceeds (what I recall of the) WUSB specs by presuming an identity > > based acceess control mechanism. (Access control list, etc.) > > Well, for once, the authorized-to-connect/authenticated are two > different concepts (as I have explained in previous emails). And WUSB devices only need the "authenticated" notion ... the other notion really should not get mixed up with this one. I've seen too much confusion caused by security code confusing the two. Way too much trouble caused by that confusion too (and when I say "trouble" I certainly include "designed-in security bugs"). > On the case of udev->state, I considered that, but rejected it due > to the following reason: a non-authorized to connect device could > be in the DEFAULT/ADDRESS/CONFIGURED or SUSPENDED states, as what > differentiates from a normal device is that drivers are not bound > to it, so effectively, it cannot be used. But again, WUSB doesn't have that notion. If (big if!!) that notion of "authorization" is going to enter the system, it should not be coupled to patches that enable WUSB. > I am still pondering how much the USB_STATE_UNAUTHENTICATHED/ > RECONNECTING states can be used for the WUSB auth model, as we need > the device up and running and ready to service requests on ep0 to > do the authentication--so that means the whole stack needs to recognize > it as a normal device. I'm pondering your pondering ... that state is part of the WUSB spec, so either that spec has fundamental problems *or* you're missing a few key points. I'm suspecting the latter. And that this is the sort of issue that becomes a lot clearer when extraneous issues (i.e. "authorization") get stripped out, and the code really implements the stuff (like moving a device -- wired or not -- through authentication states) causing the confusion, rather than being ground work for it. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel