Re: RFC/patch: authorizing (or not) devices to connect to the system

Hi All

On Tuesday 24 April 2007, David Brownell wrote:
> On Tuesday 24 April 2007, Inaky Perez-Gonzalez wrote:
> > I've been toying with some patches to implement this concept also in a
> > generic way so that it could be used to implement a control mechanism
> > for locking down systems (like for example, don't connect this kind of
> > hw, because policy won't allow it being configured).
>
> This is much the same kind of notion as the USB-OTG "Targeted
> Peripherals List" (TPL) -- a whitelist of devices a given product
> vendor supports.  (Since, as we know, so many USB peripherals are
> only marginally conformant, and OTG hosts might never get bugfixed
> once they get shipped.  A whitelist can minimize support problems.)
>
> I'd much rather see such white/black list mechanisms be uniform
> across all of USB ... and I'm a bit puzzled what this would have
> to do with wireless USB.

Hmm, this was a good backslash -- let me try to answer most of the concerns
in here. Some things are my fault as I didn't give an overview of how
it was supposed to happen.

The device authorization/or not policy is not implemented in the kernel, 
but in user space. When a device is plugged, the host has the 'default' 
policy of authorizing it to connect or not based on  
/sys/class/usb_host/X/authorized_default.

Then udev receives the notification of a new device (I have to plug this
in) and user space goes around, does his thing (lists whatever) and when
it decides to allow or deny (or leaving it to default), it sets it by 
writing to /sys/class/usbdevX/authorized. The kernel then will proceed
to finalize the connection (enumeration) or leave things as they are.

So this generic mechanism can be used by 

* OTG TPLs: by authorizing it to connect or not depending on hw compat

* WUSB: by authenticating a device and if it authenticates,
then it is authorized it to connect to the system--and hence the choice
of names. Eric, David is right here and that is the model--not to enforce
FCC or behave like Vista, this is more making sure I am talking to my 
device and not another one (think SSH keys for the host matching the IP) 
and my device is talking to me. 

* System lockdown mechanisms: don't allow the user to connect 'unsafe'
hw -- and here the 'unsafe' is so broadly defined and fuzzy that's
almost useless. 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.

This last one boils down to WUSB. When udev is told a new USB device is
connected, we go and see it is WUSB, do the authentication and if it is
'paired' and the user wants to allow it to connect (for example, this is
not mandatory at all), then the user space code will authorize it and the
enumeration process will proceed.

Hope this helps in clarifying -- and sorry for the lag, ugly busy day.

-- Iñaky

-------------------------------------------------------------------------
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