My issues with Unix device names
Posted: Fri Mar 26, 2010 8:58 am
In Unix based systems, configuration files, such as /etc/fstab, frequently refer to device names. What people often don't think about is that these device names can change on their own behind your back.
Consider the following situation:
A company has an old file server running Windows, where the R&D department stores their work. With the server sitting in the server room and accumulating dust for years, one day the dust short circuits the motherboard and the server won't start anymore. They also have a server running Linux, so they take the disk from the old computer (which is formatted with FAT32) and put it in the Linux server. The primary master is the system disk, and two hard disks filled with high resolution demonstration videos and presentations for their products are connected as primary slave and secondary master. Therefore, the disk with the R&D department's files becomes the secondary slave. To be extra sure that no one unauthorized will be able to access their important files, they create a directory called /development and assigns read, write and execute permissions to the R&D department, while denying all access for everyone else, and they mount the R&D department's old hard disk at /development/old. The Linux server also hosts the company's website, and all the demonstration videos are freely available for online viewing. One might argue that this is an insecure practice, but Linux is a well established operating system with process isolation and tight access control, so it should be no problem, right? Of course, the web server service has no access to the /development directory or its subdirectories. So, /etc/fstab looks like this:
This works out quite well, in theory.
Now, suppose one day, the power goes out. When the power comes back and the server reboots, one of the hard disks no longer functions, and isn't even detected by the computer. It's the primary slave. The server prints out an error message in the middle of one of the pages of startup messages rolling across the screen, but no one ever goes to the server room so they don't see it. Now /dev/hdb is the secondary master and /dev/hdc is the secondary slave. You can imagine what happens next. Someone logs on to their website and clicks on several videos, but they don't load. So he thinks maybe he should check if the /videos2 directory really contains anything. He navigates to /videos2 and to his surprise, he instead gets a listing of the R&D department's files. He steals all their ideas and patents them, and the company goes bankrupt.
This demonstrates how inherently insecure Linux and other Unix variants are.
In Windows, storage device names can also change, but the permanent drive letter assignments aren't to specific device names, instead they refer to the volume by an unique volume identifier.
Consider the following situation:
A company has an old file server running Windows, where the R&D department stores their work. With the server sitting in the server room and accumulating dust for years, one day the dust short circuits the motherboard and the server won't start anymore. They also have a server running Linux, so they take the disk from the old computer (which is formatted with FAT32) and put it in the Linux server. The primary master is the system disk, and two hard disks filled with high resolution demonstration videos and presentations for their products are connected as primary slave and secondary master. Therefore, the disk with the R&D department's files becomes the secondary slave. To be extra sure that no one unauthorized will be able to access their important files, they create a directory called /development and assigns read, write and execute permissions to the R&D department, while denying all access for everyone else, and they mount the R&D department's old hard disk at /development/old. The Linux server also hosts the company's website, and all the demonstration videos are freely available for online viewing. One might argue that this is an insecure practice, but Linux is a well established operating system with process isolation and tight access control, so it should be no problem, right? Of course, the web server service has no access to the /development directory or its subdirectories. So, /etc/fstab looks like this:
Code: Select all
/dev/hda1 / auto defaults 0 0
/dev/hda2 swap swap defaults 0 0
/dev/hdb1 /wwwroot/videos1 auto rw 0 0
/dev/hdc1 /wwwroot/videos2 auto rw 0 0
/dev/hdd1 /development/old auto rw 0 0
Now, suppose one day, the power goes out. When the power comes back and the server reboots, one of the hard disks no longer functions, and isn't even detected by the computer. It's the primary slave. The server prints out an error message in the middle of one of the pages of startup messages rolling across the screen, but no one ever goes to the server room so they don't see it. Now /dev/hdb is the secondary master and /dev/hdc is the secondary slave. You can imagine what happens next. Someone logs on to their website and clicks on several videos, but they don't load. So he thinks maybe he should check if the /videos2 directory really contains anything. He navigates to /videos2 and to his surprise, he instead gets a listing of the R&D department's files. He steals all their ideas and patents them, and the company goes bankrupt.
This demonstrates how inherently insecure Linux and other Unix variants are.
In Windows, storage device names can also change, but the permanent drive letter assignments aren't to specific device names, instead they refer to the volume by an unique volume identifier.
