3

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

3 Answers3

3

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

Mark Russell
  • 7,376
  • 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. – user4124 May 24 '11 at 14:53
  • 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. –  May 25 '11 at 15:06
  • 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: https://blueprints.launchpad.net/ubuntu/+spec/security-o-apparmor-dev1 – Mark Russell May 25 '11 at 15:36
  • 1
    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: https://bugs.launchpad.net/ubuntu/+bug/770565 ; and here's mine: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/786839 (opened for Natty) –  May 25 '11 at 21:12
  • Ah, also, here's another one (10.04) reported right on this site: http://askubuntu.com/questions/32565/apparmor-not-starting-with-kernel-lsm-error –  May 25 '11 at 21:16
  • 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). – Mark Russell May 25 '11 at 22:38
1

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.

user4124
  • 8,911
0

I would not be afraid of this. From the link: "The vulnerability requires a USB key, so physical access". Anyone that has physical access can change your root account password, format discs, copy and move files around, leave rootkits, reboot and use a live cd or access a USB stick from RAM during a live cd session. And this type of problem gets fixed rather quickly (the person that found this also made the fix).

Even so... I found a topic on ubuntuforums for doing special udev rules for specifically for usb: In short (more inside the link):

Create the file /etc/udev/rules.d/91-local.rules and copy this into it SUBSYSTEMS=="usb", KERNEL=="sd??", ACTION=="add", RUN+="/usr/local/bin/USB %k"

%k is the device the kernel will parse into a script USB that gets executed (sudo chmod +x /usr/local/bin/USB).

And now you can create a script called USB that can do things based on your conditions, like not mounting it (in the link is a setup for making backups).

Rinzwind
  • 299,756
  • 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.). –  May 25 '11 at 15:01
  • Yes that would help too. You need to passphrase for mounting the harddiscs so anyone else is out of luck that way! – Rinzwind May 25 '11 at 16:37