When it comes to permissions on device special files, extra vigilance is required because special files give direct access to the hardware of the machine and any mistakes in the setup of these files can lead to serious security problems if one of your users is sufficiently knowledgeable.
The device special files to which you should pay particular attention are those associated with hard disk drives and those associated with memory. Typically these will have names like:
/dev/hda /dev/hdal /dev/hda2 etc. /dev/hdb /dev/hdbl /dev/hdb2 etc. /dev/sda /dev/sdal etc. /dev/sdb etc. /dev/mem /dev/kmem
All these files should be owned by root and have permission settings that are as limited as possible, and in any case without public read or write permission. If a user managed to get read and write access to a disk or a disk partition then that user would be able to circumvent all the standard file and directory permission arrangements on that disk or partition. This is because the user would be able to access the bytes on the drive directly, just as data, without the system imposing any of the usual directory hierarchy on it. Admittedly, the user would then have the task of making sense of the data, splitting it into files and directories manually. But this is not as tough a task as it sounds, especially as it is easy to find out exactly how a file system is laid out on the disk.
A similar problem exists if a user can get read and write access to a memory special file, as these are just mapped directly onto areas of the machine's memory and would thus allow the user to see and modify memory areas in the running system.
Under Linux, another way to access the memory of the machine and the memory associated with each of the running processes is via the contents of the /proc directory. In fact, /proc and its contents do not literally appear on your hard disk even though you can do an ls /proc command and list its contents. The directory and all its contents are just dynamically fiddled into place by the kernel.
Obviously, if the memory of a running process can be accessed by a user with sufficient privilege then this will also cause security problems if someone hacks into your root account.
Terminal access to most Linux systems will be provided over a network or via the machine's console and its virtual terminals. Some systems, however, will have extra terminals connected to them via serial ports - and this can be the source of another problem. Traditionally, the permissions set on a terminal will allow write access to the terminal special file by anyone. This allows simple messages to be passed around between users using the write command. However, this is precisely the source of the problem with some serial terminals.
For many terminals, it is possible to send simple escape and command character sequences to them which can program them to perform simple actions. It is not uncommon for one of these actions to be to send characters from the terminal back to the host machine, just as though the characters had been typed on the terminal's keyboard. Given this scenario it is simple to see that a hacker, using the write command, could send a sequence of characters to your terminal which make the terminal send programmed commands back to the computer. These commands will then be executed just as though you had typed them yourself. If you happen to be logged in as root at the time... well, you get the picture.
The only way to protect yourself against an attack of this kind is to remove the public write permission from your terminal line. This can be done with the command:
$ mesg
Sadly, removing this potential problem also prevents other users from using write to send you messages, but you can't have it both ways.