Can udev be used (udev rules) to whitelist certain usb devices?

Question

Can udev be used (udev rules) to whitelist certain usb devices?

What I mean is that only devices in a list I create (containing device IDs that I can obtain with lsusb) will be passed on / processed by udev. Those not in my list should be ignored by udev as soon as possible (without even notifying the driver for the device).

I've heard about "udev rules". If you know something about how udev rules work, do you think it is possible to use them for my purposes?

You may be wondering why I want this. This is for security purposes. See more details here about such vulnerabilities: http://www.charlescurley.com/blog/archives/2011/03/13/linux_usb_vulnerability/index.html

Solution 1

A key to writing the proper rules is understanding that udev rules are applied in a certain order. The default, package-supplied rules are in /lib/udev/rules.d/. Leave those files alone. Local rules should be placed in /etc/udev/rules.d/ which takes precedence over /lib/udev/rules.d.

Your file (if you choose to create a new one) must end in .rules and it can be named as you like, however the numbered files will be processed first. If you want to override a numbered rules file, choose a higher number for your file name, or choose a file name without a number, it will run after all the numbered rules files. So the idea is: make your total blacklist rule run first and then the whilelist rules afterwards to allow the specific devices you want to allow.

It has already been pointed out however, that this attack requires physical access and such vulnerabilities are usually fixed quickly. However, what's even more interesting is the fact that if you were using Ubuntu 9.10 and above, you were never really vulnerable to this attack anyway. Since 9.10 evince's AppArmor profile would have contained the rogue process and limited it to pwning your thumbnails. See: USN-1035-1: Evince vulnerabilities

Solution 2

You need to add rules to /lib/udev/rules.d/ that will whitelist only the given devices, and blacklist all the rest.

You can read /lib/udev/rules.d/75-persistent-net-generator.rules for examples. It shows how to filter devices and select whether to activate or not the devices.

Comments

[user4124]

So you want to blacklist all USB devices and allow only certain ones to be accessible.

[user4124]

There are different types of attacks with physical access. This one does not require you to unscrew the computer or reboot it with a LiveUSB or reboot in recovery mode.

[Per]

Thanks for your insight. However, what IF my hard drive is completely encrypted (LVM+Crypt) AND the system is locked (Ctrl+Alt+L); would it make sense in this case? I think it would make sense, because in this case, the only remaining attack vectors are the computer's physical ports (USB, Firewire, HDMI etc.).

[Admin]

Yes, however Ubuntu developers don't seem to care much about AppArmor and it will work on about ~50% of the kernels. Also, there is I believe a situation where physical access is not a problem except for vulnerabilities as described in my question. That is: if the HDD is completely encrypted (LVM+Crypt), and the machine is locked (Ctrl+Alt+L) - and hence, the only remaining attack vectors are the computer's physical ports (USB, Firewire, etc.). Of course, there might be additional vulnerabilities in Gnome's lock function, but heh, we can't have everything :P.

[Mark Russell]

Hi Andrei. I'm not sure about older versions, but I don't know of any AppArmor / kernel issues in Ubuntu from 10.04 on. And far from not caring about AppArmor, Canonical employs the upstream AppArmor team. Development is quite active: blueprints.launchpad.net/ubuntu/+spec/security-o-apparmor-de‌​v1

[Rinzwind]

Yes that would help too. You need to passphrase for mounting the harddiscs so anyone else is out of luck that way!

[Admin]

Are you sure about AppArmor? Or maybe the issues are only isolated to certain users/configurations? Here's for example a bug report opened for 10.10: bugs.launchpad.net/ubuntu/+bug/770565 ; and here's mine: bugs.launchpad.net/ubuntu/+source/linux/+bug/786839 (opened for Natty)

[Admin]

Ah, also, here's another one (10.04) reported right on this site: askubuntu.com/questions/32565/…

[Mark Russell]

No I can't say I'm sure, but I don't think there are widespread problems. To be fair, your problem seems to be related to unsupported kernel modules from vbox, rather than something shipped in Ubuntu. The good news (I think) is that I tried your scenario just now on VirtualBox 4.0.8 (r71778) with Guest Additions and /etc/init.d/apparmor status worked as expected. Looks like Oracle fixed the issue (?). Hope this helps (and hopefully the fix works for 10.10 and 10.04! I only checked 11.04).