can I setup usb on linux to only support input devices?
June 4, 2008 12:10 AM Subscribe
Does anyone know a good way to make input devices be the only thing recognized by usb on linux?
I need to set some machines so that only the keyboard and mouse ( and maybe wacom) can be used on a linux box ( RHEL WS5). I need to keep the machines from doing things like mounting flash drives.
I have looked at usb hardware locks, but that seems stupid to me ( they cost alot and are a pain to deal with).
Also, these boxes are Mac Pros ( so no turning usb ports off in bios)
I need to set some machines so that only the keyboard and mouse ( and maybe wacom) can be used on a linux box ( RHEL WS5). I need to keep the machines from doing things like mounting flash drives.
I have looked at usb hardware locks, but that seems stupid to me ( they cost alot and are a pain to deal with).
Also, these boxes are Mac Pros ( so no turning usb ports off in bios)
You could probably unload (with rmmod) and remove the usb-storage driver from /lib/modules/<your kernel version>/kernel/drivers/usb/storage. This would prevent USB mass storage devices from working on the computer.
posted by knave at 12:29 AM on June 4, 2008
posted by knave at 12:29 AM on June 4, 2008
You can also use udev rules to restrict unwanted devices to a specific group, have a look at the documentation - don't know if this would apply to Macs though.
posted by ghost of a past number at 12:50 AM on June 4, 2008
posted by ghost of a past number at 12:50 AM on June 4, 2008
Compile your own kernel with usb mass storage drivers not included, or compile with only USB HID drivers included. Check documentation on how to download the kernel source code for your distro, configuring it according to your preferences and compiling and installing it.
It sounds more difficult than it is. Getting the source code off the repos should be a single yum/rpm command. Then, just go into the kernel source directory and copy over the old .config and do a make menuconfig. That will give you an ncurses based menu where you can add/remove/modify different kernel components. If you're unsure of something, leave it in. Exit, and check the docs on how to compile and install the newly compiled kernel and adding an entry in the grub configuration.
Good luck!
posted by cyanide at 2:16 AM on June 4, 2008
It sounds more difficult than it is. Getting the source code off the repos should be a single yum/rpm command. Then, just go into the kernel source directory and copy over the old .config and do a make menuconfig. That will give you an ncurses based menu where you can add/remove/modify different kernel components. If you're unsure of something, leave it in. Exit, and check the docs on how to compile and install the newly compiled kernel and adding an entry in the grub configuration.
Good luck!
posted by cyanide at 2:16 AM on June 4, 2008
These are Macs running Linux?
If you want to stop end-users being able to mount hot-plugged devices, then that's a job for the hal preferences, plus possibly making sure that the users aren't in the relevant groups (plugdev?). If you want to stop the devices being made available at all, then that requires editing the udev preferences (in /etc/udev) as udev handles hotplug driver loading / unloading.
Alternatively of course, the brute force approach is to compile a kernel that doesn't have any of the relevant drivers at all...
posted by pharm at 2:39 AM on June 4, 2008
If you want to stop end-users being able to mount hot-plugged devices, then that's a job for the hal preferences, plus possibly making sure that the users aren't in the relevant groups (plugdev?). If you want to stop the devices being made available at all, then that requires editing the udev preferences (in /etc/udev) as udev handles hotplug driver loading / unloading.
Alternatively of course, the brute force approach is to compile a kernel that doesn't have any of the relevant drivers at all...
posted by pharm at 2:39 AM on June 4, 2008
FIrst, let me warn you that I'm on an Ubuntu machine. I think that RedHat is essentially the same in these matters these days, but I am not sure.
You can put directives in a file in /etc/modprobe.d. For instance, if you determine that you want the usb-storage module to load, you would write in your file 'blacklist usb-storage' (if your modprobe doesn't know 'blacklist' -- I think it's a recent addition -- then the alternative spelling is 'install usb-storage /bin/true').
When installing a new kernel version you'll need to check that the blacklist is still accurate; a new driver with a new name might be added that you don't want your users to be able to load.
Using groups with udev and reconfiguring your kernel are also good suggestions. For udev, look in /etc/udev/rules.d for rules that set GROUP= or MODE=; this is what allows special device files to be accessible by regular users without use of sudo/su. You could simply remove the GROUP= and MODE= settings, so that the default (read/write by root) is retained. Or you can note the groups that devices get placed in and make sure your users aren't members of those groups. When upgrading the package that these udev rules come from, you'll have to check things over again (I think redhat's rpm puts either the old file or the new file with a ".rpmXXX" extension; then you have to manually figure out what to do about it.)
Finally, there's the option of recompiling your kernel. I would be least excited about that, because that case is when you have the most work to do after a new kernel (e.g., a security update) is released.
Lastly, and maybe this goes without saying, if your users have su/sudo access there's nothing you can do to prevent them undoing these measures. It also won't stop them using bootable media.
posted by jepler at 5:11 AM on June 4, 2008
You can put directives in a file in /etc/modprobe.d. For instance, if you determine that you want the usb-storage module to load, you would write in your file 'blacklist usb-storage' (if your modprobe doesn't know 'blacklist' -- I think it's a recent addition -- then the alternative spelling is 'install usb-storage /bin/true').
When installing a new kernel version you'll need to check that the blacklist is still accurate; a new driver with a new name might be added that you don't want your users to be able to load.
Using groups with udev and reconfiguring your kernel are also good suggestions. For udev, look in /etc/udev/rules.d for rules that set GROUP= or MODE=; this is what allows special device files to be accessible by regular users without use of sudo/su. You could simply remove the GROUP= and MODE= settings, so that the default (read/write by root) is retained. Or you can note the groups that devices get placed in and make sure your users aren't members of those groups. When upgrading the package that these udev rules come from, you'll have to check things over again (I think redhat's rpm puts either the old file or the new file with a ".rpmXXX" extension; then you have to manually figure out what to do about it.)
Finally, there's the option of recompiling your kernel. I would be least excited about that, because that case is when you have the most work to do after a new kernel (e.g., a security update) is released.
Lastly, and maybe this goes without saying, if your users have su/sudo access there's nothing you can do to prevent them undoing these measures. It also won't stop them using bootable media.
posted by jepler at 5:11 AM on June 4, 2008
jepler: if your users have su/sudo access there's nothing you can do to prevent them undoing these measures.
One small point: in /etc/sudoers you may explicitly define which programs certain users/groups are allowed to run. One needn't give full root privileges when they only need to run a command or two
posted by philomathoholic at 7:31 AM on June 4, 2008
One small point: in /etc/sudoers you may explicitly define which programs certain users/groups are allowed to run. One needn't give full root privileges when they only need to run a command or two
posted by philomathoholic at 7:31 AM on June 4, 2008
Response by poster: I am marking zsazsa's answer as best, but I didn't try the rest. I am hoping to go back at try one of the other solutions so as to not be such a brute force approach. But I don't have time as of yet. But zsazsa's method does work.
posted by brent_h at 2:21 PM on June 4, 2008
posted by brent_h at 2:21 PM on June 4, 2008
« Older How do I transfer money overseas? | How does my former coworker get rid of this kid? Newer »
This thread is closed to new comments.
posted by zsazsa at 12:29 AM on June 4, 2008