Section 6.2 Stopping Access to IO Devices
6.2 Stopping Access to I/O Devices
One of the innovations of UNIX is that it gives file names to hardware devices and allows them to be accessed as if they were regular files by user programs. This wonderful innovation freed programmers from having to add special code to any program that wanted to access devices. Even some newer operating systems failed to adopt this innovation of uniformity of I/O not only for devices versus disk files but also in having only a single base file type that a program must know about rather than the sequential, random, ISAM, BDAM, etc.[1]
In almost all cases, the device files are located in /dev or a subdirectory of /dev. Except where noted, all devices should be owned by root. To summarize, these recommended permissions are listed in Table 6.2.
On a secure system, you certainly do not want ordinary users to access disk devices directly because that would allow them to bypass all that file system security. Similarly, you do not want users to have direct access to the line printer because that would defeat lpr's spooling facility. The disk devices presently are /dev/hd?* for IDE disks, /dev/sd?* for SCSI disks, and /dev/md?* for RAID devices. They might change in the near future to not have the device name (hd?* versus sd?*) be determined by the hardware type. Users should not access the mouse device directly; gpm (general purpose mouse) or X will read the device and they both run as root. The mouse normally is the symbolic link /dev/mouse pointing either to the serial device that it is connected to or to the PS2 device, /dev/psaux. You do not want users to have access to most tty devices because that would allow users to read each other's keystrokes. The serial tty devices are /dev/ttyS* with the dialer version[2] being /dev/cua*. (This device name is changing in newer systems.)
Normally, the /dev/ttyS* devices are mode 600 and this is changed to 620 by the login process. Additionally, it changes a device's ownership to that of the logged-in user. Although some UNIX systems set these devices to mode 622 for the write command, even most older Linux systems instead set it to mode 620, with a group of tty, and have the write program be set-GID to tty. This prevents other users from writing directly to your screen to protect against a sinister attack, described in "Function Key Hijacking" on page 160. The write program filters out escape sequence to protect against these attacks. While protecting against severe problems, this scheme still allows a denial of service attack via write joe@pentacorp < /dev/ttyp5 A user is always free to set her terminal to "do not disturb" by invoking mesg n or chmod 600 to the device. On secure systems where users are not all trusted, such as an ISP allowing dial-in accounts or a college, placing /usr/bin/mesg n in the system's shell startup scripts, /etc/profile and /etc/csh.login, would be an excellent idea. Ensure that any very long-time users are not setting their ttys to mode 622. For improved security, most Linux distributions support the /dev/cua* devices being mode 600 with an owner and group of uucp. In this configuration, the /usr/bin/cu program (call another UNIX system) also may have an owner and group of uucp and be both set-UID and set-GID. This will prevent users from having unrestrained access to the devices. The cu program will enforce a file lock (Mutex semaphore) so that only one user at a time may access a particular device. If anyone is still using UUCP, it also will "play nice" with cu in this configuration. The subtle differences in how the drivers handle these two aspects of the same set of devices allow such things as having a getty running on, say, /dev/ttyS0 waiting for the driver to detect Ring Indicator (RI) from an incoming call to allow getty's open of the device to complete. Prior to receiving RI, a local user can open /dev/cua0 via cu to initiate an outgoing connection. The devices /dev/tty[0-9]* are for the virtual consoles, sort of an economically disadvantaged person's windowing system. Most people bring up X and then forget about it. However, it is a wonderful innovation that can be very useful in setting systems up, and for systems that do not need X nor want its overhead (such as servers and high-security systems). Many forget about the virtual console memory devices, /dev/vcs[0-9]* and /dev/vcsa[0-9]*. These allow anyone with the permissions to read or write the memory containing the characters. The same rules for tty devices apply here. In most Linux distributions these devices are mode 620, offering protection. For the highest security, these should be 600. /dev/console is the original console and should be mode 600 in secure installations. As it was with the other tty devices so it is with /dev/tty[p-z]?, the "pseudo tty" side of pseudo ttys. This is the side that telnet's daemon, and similar programs, use to "pretend" to be a terminal to the shell, editor, or whatever program is running on the server system. Different rules apply to the "control" side of pseudo ttys, /dev/pty*. The control side /dev/pty* devices are mode 666 so that anyone may initiate a pseudo tty pipe but only a single process may have a control device open at a time. Thus, a program, such as telnetd, tries to open each of these in turn. If a particular one is in use already, the open() will fail and each subsequent one will be tried until one is found that is not already in use. The pseudo tty is an extremely useful Berkeley innovation. The pseudo tty was the next step in the "devices are files" concept. Although a program that reads and writes an ordinary file will work just fine with most devices, such as a tty device, the latter has additional features that savvy programs such as the shells and editors take advantage of. These involve such things as control of process groups for cleanly running programs in background and varying degrees of "raw mode" to allow the shell to read characters before a newline is received for command completion. The principal reason for pseudo ttys was for correct operation under telnet. The use of pseudo ttys allows one's login shell, Mail, vi, and even stty to work correctly even though they are not really talking to a tty device. Instead they are talking, via a pseudo tty, to the telnetd daemon which talks over a TCP connection to the telnet client on the other machine, which is connected to a real tty device...or maybe a telnet daemon connected to... When the user types a "^C" to generate an interrupt signal (SIGINT), this signal is received by the telnet client process. It then sends a special message to the telnet daemon, which then makes a special system call that causes an interrupt signal to be sent to all the processes connected to "the other end" of the pseudo tty device. Although the process that initiates the pseudo tty (in.telnetd in this case) has to have special "knowledge" of pseudo ttys, the processes on the other end, the shell, editor, Mail, etc., do not. A process's own "controlling" tty may be referenced via /dev/tty. It is the device that starts out being the process's standard input, output, and error and the device where keyboard-generated signals such as SIGINT (^C) originate from. Because it always refers to a process's own tty device a process cannot "get to" another user's /dev/tty. For this reason it always should be mode 666. It is discussed in more detail in "Why /dev/tty Is Mode 666" on page 273. The /dev/null device is sometimes called a data sink, similar to a heat sink. If you are not interested in the output of a program, typically because you are only interested in the program's side effects, its output can be redirected to /dev/null as the output might to an ordinary file. The /dev/null device will return "success" on each write call but throw the data away. Although some worry about sending /dev/null too much data and filling it up, its design prevents this. All it does is set the "number of bytes written" to the number requested and returns. This makes it extremely efficient. It does not even read the program's output buffer. It may similarly be used as a zero-length input file. For reads, it simply sets the number of bytes read to zero, the EOF (end of file) indication, and returns. There is no danger of one program reading /dev/null at the same time as someone else writing to it seeing the other program's output. Because it is a resource available for everyone, like /dev/tty, it should be mode 666. Some sites have used chmod to change /dev/null's mode to 777 so it also can be used as "the null shell script" for similar reasons. Although this is harmless, it is not portable and, perhaps, not a good idea to rely on. /dev/zero is similar to /dev/null except that on reads it returns a buffer of whatever size the program requests consisting of binary zeros (NULs). It should be mode 666 for the same reasons as /dev/null. When /dev/random or /dev/urandom are read, they return very random bytes. These bytes are not even of the repeatable variety of the random() library routines because the kernel actually randomizes the data with the timing of console keystrokes and other environmental "noise" and other factors. They were introduced with the 1.3.30 Linux kernel. /dev/random and /dev/urandom are suitable for generating random data for use in cryptographic applications. They actually track how much random noise has been generated versus how many random bytes have been read. If the randomness has temporarily been used up, reads from /dev/random block until more randomness is received. /dev/urandom will generate pseudo-random data in this situation. Because they are intended for reading only, both should be mode 644. You certainly do not want users to have access to mem or kmem because these grant access to the system's running main memory (RAM). These devices are /dev/mem and /dev/kmem and should be an owner of root, a group of kmem, and be mode 600 or 640. You do not want ordinary users to be able to access most other devices. There are a few devices that you might want to grant users access to. You might want to allow your users to read and write the floppy devices, /dev/fd*. Some sites will have the floppy device be mode 666; some will have it be mode 660 with a group of floppy. Users allowed to use the floppy device would be members of the floppy group in /etc/group. Similarly, you might want to allow users to make their own tape backups or restore from tape. Traditionally, /dev/rmt0 will be the tape device or a link to it. /dev/ftape and /dev/rft0 are other common names. To allow users to use them, the mode would be 666. Sites that are concerned that users might pirate their data definitely should use mode 600 for the floppy and tape devices as well as any writable CD-ROM devices. They will want to limit mail out of the system as well. You might want to allow your users to have write access to the sound card. They should not have read access, because this would allow anyone on the system to capture sound from the microphone, thus eavesdropping on whatever is being said. The audio device is /dev/audio. This permissive mode would be 622; the more restrictive mode would be 600. The CD-ROM normally is /dev/scd* for SCSI devices and /dev/hd* for IDE devices; some sites will use /dev/cd*. You might want it accessible by all if you want to allow users to listen to music CDs. Root permission normally is required to mount an ISO 9660 CD-ROM but permission may be granted to ordinary users to mount a CD-ROM (with restrictions) by using the -o flag in /etc/fstab. If you have confidential data on CD-ROMs, such as updates to databases, you will probably want to restrict access to root. 6.2.1 Why /dev/tty Is Mode 666The /dev/tty concept is another clever one from the earliest UNIX days. With I/O redirection (with <, >, |, and friends) comes the problem of how a program can access the actual tty (terminal) that it was invoked from. Although stderr (file descriptor 2) is an excellent place to write most error messages, sometimes a programmer really wants to access the terminal in spite of redirection. The /dev/tty device file always points to the controlling tty that the program was started from to resolve this matter. Because of this, a malicious user writing to or reading from /dev/tty can only access her own terminal and there is no security problem.
6.2.2 Virtual Console Buffer Vulnerability
Many people forget that virtual terminals store about 170 lines in the buffer and that the "clear" escape sequence does not erase this. The best solution is to ensure that /etc/issue has at least 170 lines in it. Also, there might be a vulnerability in the alternate buffer that vi switches to during editing. 6.2.3 Encrypted Disk DriverAlthough SSH and SSL work great for encrypting communication channels and PGP is great for encrypting files, typically for transmission via a network or on magnetic or optical media, they are not ideal for protecting lots of data on disk. The problem with PGP is that to use the file it must be converted to clear text and, when manipulation is done, you must remember to encrypt it again. Nobody will remember to do this each and every time. This is not PGP's fault; people are not good at remembering to do a repetitive task each time. What is needed is a disk driver that automatically encrypts the data as it is written to disk and decrypts it as it is read by a program. Enter PPDD (Practical Privacy Disk Driver), a device driver for Linux that sits "on top of" a disk driver similarly to the RAID disk driver, md. PPDD presents an interface that looks like a disk partition to the kernel layers above and it interacts with the raw disk driver (or, perhaps, RAID) below. PPDD uses the Blowfish encryption algorithm in assembly code and you may put a standard ext2, ext3, or reiser file system on top of it. You may use it for the root file system as well as the swap partition. Using it for swapping (paging) prevents this commonly overlooked vulnerability, for example, of confidential data left in the swap partition that was in a program's virtual memory space. PPDD source, specification, man page, and HOWTO are available at: http://linux01.gwdg.de/~alatham/ppdd.html Its write performance is reported as being half that of an unencrypted disk and its read performance as being one-fourth. Linux's disk I/O buffering should improve this for normal use. There are several other free disk encryption packages for Linux including: www.kerneli.org/ ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/cfs-1.1.2.tar.gz |
| Top |
EAN: N/A
Pages: 260
- Article 250 Grounding and Bonding
- Article 334 Nonmetallic-Sheathed Cable Types NM, NMC, and NMS
- Article 400: Flexible Cords and Cables
- Article 424: Fixed Electric Space Heating Equipment
- Example No. D10 Feeder Ampacity Determination for Adjustable-Speed Drive Control [See 215.2, 430.24, 620.13, 620.14, 620.61, Tables 430.22(E), and 620.14]