Can udev rules do this?

[depontius]

A while back on Bruce Schneier's blog there was some discussion of bogus USB devices, both ordinary and extraordinary. An ordinary bogus USB device simply comes with the free bonus of a virus or trojan. An extraordinary bogus USB device can be more sinister, one option being a composite device. So in addition to that flash memory you think you've just plugged in, you've also plugged in some other device, one example being a keyboard that proceeds to type in the commands to inject something nasty.

t would seem to me to perhaps be within the realm of udev to :
1 - Keep persistent track of every USB device which has ever been plugged in, and what type of device it is.
2 - Upon seeing a new device inserted, pop a dialog telling exactly what that device is, and requesting confirm/deny to attach it. If no X, do it on the console.
3 - If a device with an old serial number is inserted, make sure that it's the same type of device it was when first inserted/recorded.

The key here is that this stuff happens after insertion, but before a driver is bound to the device, presumably before any device node is created. I've glanced through the "Writing udev rules" guide, though not in depth, and it appears to me that everything happens after the device node is created - which is probably too late. But I haven't searched exhaustively, and what I'm asking about doesn't appear to be ordinary stuff, either.
_________________
.sigs waste space and bandwidth

[redagadir]

good idea, but do those devices exist in reality (I'm not speaking about FPGA based prototypes)?

[depontius]

From what I've heard, yes. Though probably only as fpga prototypes, since it's not exactly a mass-market item.
_________________
.sigs waste space and bandwidth

[salahx]

Device binding already occurs before udev even gets the notifcation signal - its already too late at that point. You can unbind the device from the drivers, but you can't prevent the initial bind. You might not even be able to stop the device node from being created if devtmpfs is being used. You can unlink it afterwards, but of course; both problems are racy.

In the case of USB storage devices, this would be better handled by udisks; for network devices, NetworkManager; for input devices X11 (to work in the terminal you'd something like udisks for input devices - the name uinput is already taken for something else, though) - all of which would use PolicyKit to pop up the dialog.

[depontius]

My impression was that though the device node may be created, driver binding didn't happen until after udev was called, in which case I couldn't prevent the device from being created, but I could prevent a driver from being bound to it. A device with no driver shouldn't be a big threat, especially if the device is promptly "disappeared" before some other exploit could be brought to bear to bind a driver.
_________________
.sigs waste space and bandwidth