[patch 00/17] Authorizing (or not) USB devices to connect #4

Hi All

Yet another iteration, addressing GregKH's concerns. Please see below
the changelog for the rationales.

Try #4

- Reorder patches so device authorization is always disabled and won't
  break in case of a bisect
- Moved sysfs files from class/usb_host/hostX to usb/devices/usbX
  (moving to the controller was quite unusable as there was no quick
  way to track back usb/device/X to the host controller)
- Include already posted fix to choose_address() generation. 
- New: Added a wusb_dev pointer to the 'struct usb_device'. Need this
  to be able to cleanup all the resources that we take on device removal.
- New: don't try to set address on Wireless USB devices, as that has
  been done already and will be finalized when crypto authentication
  is done.

Try #3

- ported over to 2.6.22
- added docs in Documentation/usb
- Moved from using device class to the device directory
- add usb_dev_reset_delayed() [I forgot to merge it in the last
  patchset], as suggested by gregkh.
- Teach choose_address() about the slightly diferent addressing scheme
  we use for WUSB devices.


As I indicated before, as part of the work for Wireless USB, I need to
introduce in the USB stack the concept of unauthorized vs authorized
device. 

WUSB introduces the idea of authenticated (vs unauthenticated) device,
so that you have an standarized way to establish strong crypto between
your host and your device. Before being able to do anything useful we
have to authenticate a device. This even includes reading string
descriptors; for what it matters, the unauthenticated device is able
only of authenticating.

Because authentication happens using (wireless) USB requests, the USB
stack has to be up and running in what respects to its knowledge of
the device (so we can run URBs). 

As well, we'll need to contact user space to obtain pairing data
(shared secret keys, etc for out-of-band association using the
Cable-Based-Association model), confirming identity (for numeric
association, similar to bluetooth's) and user input from conditioning
for allowing a device to connect to the system or not.

So I came up with the idea that maybe it was easier to dissociate the
'wusb authentication' from the 'authorization to connect to the
system', and so does this patchset. At the end the process will
become:

1. a wusb device wants to connect to the system

2. system 'connects' it as unauthenticated/unauthorized; device is
   partially connected (no drivers are bound, no configuration is
   selected). 

3. user space receives a new device notification. user can decide if
   to ignore the connection request (end)

4. user space decides to authenticate the system (authentication
   interaction happens through sysfs); if it fails, break.

   $ method yet TBD, working on it...

5. authentication succeeds, user space authorizes the device to
   connect; device is fully enumerated.

   $ echo 1 > /sys/class/usb_dev/X/authorize

6. Use the device...

Thus, this patchset provides the means to do that; means to
authorize/deauthorize a device from user space, that effectively means
configuring or unconfiguring it (plus associated headaches). Because
it is fully dissasociated from the WUSB devices, it can be used for
all kinds of USB devices.

Other benefits/thinkings are:

 - The authentication (WUSB or other) process is completely separate,
   and is orthogonal to this.

   WUSB authentication is quite complex (I'd like to say is a pain in
   the ass) that requires in the most simple case (when the secrets
   have been exchanged out of band) at least four USB transactions if
   all things are ok (citing by memory). Numeric association takes
   even more. All this must be done in close collusion with user
   space, who manages the secrets database. The further away it is
   from the mechanism and the USB core, the better.

 - System lockdown: Could be used to enforce a policy of USB device
   connection that some security-paranoid organizations might enjoy
   (for example: don't allow to plug USB dongles that could be used to
   copy sensitive data or allow only the ones that have an approved
   crypto system with keys signed by the CA...etc...<insert your
   paranoid method here>). [*1]

 - Could also be used to implement black/white lists for devices that
   aren't compliant, etc, fully controlled from user space.

This has been compiled against 2.6.21-rc7 (2.6.21) should work. When
trying it against 2.6.22-rcsomething I saw a conflict in one of the
patches, but doesn't seem to be *that* serious. Most of the stuff
should be ok.


[*1] Cited from a previous email I sent: A case that comes to mind are
medical devices, where only certain configurations are tested and FDA
certified--(so it is a white list of devices). Udev checks against the
whitelist. Device could trick the host yes, but that's why the
enforcing mechanism is not in the kernel, so your user space sw called
by udev figures out how to do it so that it is good enough. The kernel
only cares about being said to authorize it to connect or not via the
sysfs interface.

--

Inaky

-------------------------------------------------------------------------
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/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel