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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.