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,396
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
  • 9,241
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
  • 309,379