Udev rules and the management of the plumbing layer

Posted Aug 13, 2008 13:00 UTC (Wed) by chsnyder (guest, #52714)
Parent article: Udev rules and the management of the plumbing layer

Thanks for the backgrounder.

I discovered recently that my Debian boxes will assign /dev/sda1 to a usb drive, rather than
to the internal scsi drive that Debian booted from. This is a gaping security hole to say the
least.

So can I change this behavior by modifying Marco's lovely ruleset? Guess I'll find out.

I know, I should use disk labels or uuids... but then why doesn't the Debian Installer use
disk labels or uuids?

to post comments

Udev rules and the management of the plumbing layer

Posted Aug 13, 2008 17:49 UTC (Wed) by cortana (subscriber, #24596) [Link] (3 responses)

How is that a security flaw? If it really is so, please please *please* file a bug so it can
be fixed!

Udev rules and the management of the plumbing layer

Posted Aug 14, 2008 11:02 UTC (Thu) by i3839 (guest, #31386) [Link]

If it happens in initramfs then plugging an USB stick in while booting will 
give you control over the machine. Which is only relevant if the machine
is protected in other ways, or else they could boot from something else
anyway.

Not sure how it can be abused after bootup though, except by causing
confusion.

Udev rules and the management of the plumbing layer

Posted Aug 14, 2008 13:23 UTC (Thu) by chsnyder (guest, #52714) [Link] (1 responses)

Well okay, you need physical access to the box, which is pretty much game over in terms of
security anyway, so this is more of an annoyance than a security issue.

The system boots from internal scsi raid, but after kernel loads scsi and usb drivers, it
remounts the filesystems according to /etc/fstab. Problem is, the usb drive is seen first so
gets /dev/sda and the boot drive gets /dev/sdb. 

Bootup craps out because the usb drive doesn't have /sbin/init. I was thinking that if the usb
drive had a full, working Linux system on it, an attacker would have control of the system.
But lets face it, if someone can get to the box, plug in a usb drive, and reboot, you have
bigger problems.

I'll file a bug, but I remember seeing an earlier one that said that device assignments aren't
guaranteed, so use labels or uuids. The bug in that case should be filed on the installer.

Risks of device naming

Posted Aug 17, 2008 20:14 UTC (Sun) by dark (guest, #8483) [Link]

I think it's still a security problem. You might have stuck in a USB stick in order to transfer data from it, and forgotten to take it out before rebooting. If that USB stick has a boot-time virus then you lose your system, even though it was never your intent to run any code from it.

Udev rules and the management of the plumbing layer

Posted Aug 14, 2008 1:31 UTC (Thu) by pkern (subscriber, #32883) [Link]

Not that I would see a security flaw, rather an annoyance, I think there were problems with
Grub and UUID booting that were resolved recently (at least in Debian)...

Udev rules and the management of the plumbing layer

Posted Aug 14, 2008 13:56 UTC (Thu) by cortana (subscriber, #24596) [Link]

BTW, it's the kernel itself that decides what is sda and what is sdb. Udev just uses the
kernel names for such devices.

Udev also sets up symlinks in /dev/by-{id,path,uuid,label} that will always point at the
device containing the correct filesystem. These, or the UUID= or LABEL= syntax should be used
when referring to your filesystems.

Maybe it's just that the installed still uses the 'legacy' device paths in the /etc/fstab file
that it generates. That should really be changed, but it may well be too late in the release
cycle to start on it now.