Inaky Perez-Gonzalez | 732bb9e | 2007-07-31 20:34:08 -0700 | [diff] [blame] | 1 | |
| 2 | Authorizing (or not) your USB devices to connect to the system |
| 3 | |
| 4 | (C) 2007 Inaky Perez-Gonzalez <inaky@linux.intel.com> Intel Corporation |
| 5 | |
| 6 | This feature allows you to control if a USB device can be used (or |
| 7 | not) in a system. This feature will allow you to implement a lock-down |
| 8 | of USB devices, fully controlled by user space. |
| 9 | |
| 10 | As of now, when a USB device is connected it is configured and |
| 11 | it's interfaces inmediately made available to the users. With this |
| 12 | modification, only if root authorizes the device to be configured will |
| 13 | then it be possible to use it. |
| 14 | |
| 15 | Usage: |
| 16 | |
| 17 | Authorize a device to connect: |
| 18 | |
| 19 | $ echo 1 > /sys/usb/devices/DEVICE/authorized |
| 20 | |
| 21 | Deauthorize a device: |
| 22 | |
| 23 | $ echo 0 > /sys/usb/devices/DEVICE/authorized |
| 24 | |
| 25 | Set new devices connected to hostX to be deauthorized by default (ie: |
| 26 | lock down): |
| 27 | |
| 28 | $ echo 0 > /sys/bus/devices/usbX/authorized_default |
| 29 | |
| 30 | Remove the lock down: |
| 31 | |
| 32 | $ echo 1 > /sys/bus/devices/usbX/authorized_default |
| 33 | |
| 34 | By default, Wired USB devices are authorized by default to |
| 35 | connect. Wireless USB hosts deauthorize by default all new connected |
| 36 | devices (this is so because we need to do an authentication phase |
| 37 | before authorizing). |
| 38 | |
| 39 | |
| 40 | Example system lockdown (lame) |
| 41 | ----------------------- |
| 42 | |
| 43 | Imagine you want to implement a lockdown so only devices of type XYZ |
| 44 | can be connected (for example, it is a kiosk machine with a visible |
| 45 | USB port): |
| 46 | |
| 47 | boot up |
| 48 | rc.local -> |
| 49 | |
| 50 | for host in /sys/bus/devices/usb* |
| 51 | do |
| 52 | echo 0 > $host/authorized_default |
| 53 | done |
| 54 | |
| 55 | Hookup an script to udev, for new USB devices |
| 56 | |
| 57 | if device_is_my_type $DEV |
| 58 | then |
| 59 | echo 1 > $device_path/authorized |
| 60 | done |
| 61 | |
| 62 | |
| 63 | Now, device_is_my_type() is where the juice for a lockdown is. Just |
| 64 | checking if the class, type and protocol match something is the worse |
| 65 | security verification you can make (or the best, for someone willing |
| 66 | to break it). If you need something secure, use crypto and Certificate |
| 67 | Authentication or stuff like that. Something simple for an storage key |
| 68 | could be: |
| 69 | |
| 70 | function device_is_my_type() |
| 71 | { |
| 72 | echo 1 > authorized # temporarily authorize it |
| 73 | # FIXME: make sure none can mount it |
| 74 | mount DEVICENODE /mntpoint |
| 75 | sum=$(md5sum /mntpoint/.signature) |
| 76 | if [ $sum = $(cat /etc/lockdown/keysum) ] |
| 77 | then |
| 78 | echo "We are good, connected" |
| 79 | umount /mntpoint |
| 80 | # Other stuff so others can use it |
| 81 | else |
| 82 | echo 0 > authorized |
| 83 | fi |
| 84 | } |
| 85 | |
| 86 | |
| 87 | Of course, this is lame, you'd want to do a real certificate |
| 88 | verification stuff with PKI, so you don't depend on a shared secret, |
| 89 | etc, but you get the idea. Anybody with access to a device gadget kit |
| 90 | can fake descriptors and device info. Don't trust that. You are |
| 91 | welcome. |
| 92 | |