|| ||email@example.com, "Alan Stern" <firstname.lastname@example.org>,
"David Brownell" <email@example.com>,
|| ||[patch 00/16] Authorizing (or not) USB devices to
|| ||Tue, 10 Jul 2007 12:44:56 -0700|
This is another iteration of the authorization patches. Below I
include the same design/rationale for the implementation. Since try
#2, this is what has changed:
- 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.
Can we get in the .23 merge window?
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
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
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
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
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.
To unsubscribe, use the last form field at: