aboutsummaryrefslogtreecommitdiff
path: root/Documentation/usb/authorization.txt
blob: c7e985f05d8f9f1ecd433ffe41fec1e199e8b898 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123

Authorizing (or not) your USB devices to connect to the system

(C) 2007 Inaky Perez-Gonzalez <inaky@linux.intel.com> Intel Corporation

This feature allows you to control if a USB device can be used (or
not) in a system. This feature will allow you to implement a lock-down
of USB devices, fully controlled by user space.

As of now, when a USB device is connected it is configured and
its interfaces are immediately made available to the users.  With this
modification, only if root authorizes the device to be configured will
then it be possible to use it.

Usage:

Authorize a device to connect:

$ echo 1 > /sys/bus/usb/devices/DEVICE/authorized

Deauthorize a device:

$ echo 0 > /sys/bus/usb/devices/DEVICE/authorized

Set new devices connected to hostX to be deauthorized by default (ie:
lock down):

$ echo 0 > /sys/bus/usb/devices/usbX/authorized_default

Remove the lock down:

$ echo 1 > /sys/bus/usb/devices/usbX/authorized_default

By default, Wired USB devices are authorized by default to
connect. Wireless USB hosts deauthorize by default all new connected
devices (this is so because we need to do an authentication phase
before authorizing).


Example system lockdown (lame)
-----------------------

Imagine you want to implement a lockdown so only devices of type XYZ
can be connected (for example, it is a kiosk machine with a visible
USB port):

boot up
rc.local ->

 for host in /sys/bus/usb/devices/usb*
 do
    echo 0 > $host/authorized_default
 done

Hookup an script to udev, for new USB devices

 if device_is_my_type $DEV
 then
   echo 1 > $device_path/authorized
 done


Now, device_is_my_type() is where the juice for a lockdown is. Just
checking if the class, type and protocol match something is the worse
security verification you can make (or the best, for someone willing
to break it). If you need something secure, use crypto and Certificate
Authentication or stuff like that. Something simple for an storage key
could be:

function device_is_my_type()
{
   echo 1 > authorized		# temporarily authorize it
                                # FIXME: make sure none can mount it
   mount DEVICENODE /mntpoint
   sum=$(md5sum /mntpoint/.signature)
   if [ $sum = $(cat /etc/lockdown/keysum) ]
   then
        echo "We are good, connected"
        umount /mntpoint
        # Other stuff so others can use it
   else
        echo 0 > authorized
   fi
}


Of course, this is lame, you'd want to do a real certificate
verification stuff with PKI, so you don't depend on a shared secret,
etc, but you get the idea. Anybody with access to a device gadget kit
can fake descriptors and device info. Don't trust that. You are
welcome.


Interface authorization
-----------------------
There is a similar approach to allow or deny specific USB interfaces.
That allows to block only a subset of an USB device.

Authorize an interface:
$ echo 1 > /sys/bus/usb/devices/INTERFACE/authorized

Deauthorize an interface:
$ echo 0 > /sys/bus/usb/devices/INTERFACE/authorized

The default value for new interfaces
on a particular USB bus can be changed, too.

Allow interfaces per default:
$ echo 1 > /sys/bus/usb/devices/usbX/interface_authorized_default

Deny interfaces per default:
$ echo 0 > /sys/bus/usb/devices/usbX/interface_authorized_default

Per default the interface_authorized_default bit is 1.
So all interfaces would authorized per default.

Note:
If a deauthorized interface will be authorized so the driver probing must
be triggered manually by writing INTERFACE to /sys/bus/usb/drivers_probe

For drivers that need multiple interfaces all needed interfaces should be
authroized first. After that the drivers should be probed.
This avoids side effects.