As we noted in Chapter 2, Policies and Guidelines , there are several different aspects to computer security. Integrity is, in most environments, the most important aspect of computer security. Paradoxically, integrity is also the aspect of security that has also been given low priority by practitioners over the years. This is so, in large part, because integrity is not the central concern of military security - the driving force behind most computer security research and commercial development over the past few decades. In the military model of security, we want to prevent unauthorized personnel from reading any sensitive data. We also want to prevent anyone from reading data that may not be sensitive, but that can be combined with other data to compromise information. This is called confidentiality and is of paramount importance in the military view of computer security.
Confidentiality is a weird priority. It leads us to security policies in which it is acceptable, at some level, to blow up the computer center, burn the backup tapes, and kill all the users - provided that the data files are not read by the attacker!
In most commercial and research environments, integrity is more important than confidentiality. If integrity were not the priority, the following scenarios might actually seem reasonable:
These examples are obviously silly in most settings. We do care about integrity: protecting our data from unauthorized modification or deletion. In many commercial environments, both confidentiality and integrity are important, but integrity is more important. Most banks, for example, desire to keep the account balances of their depositors both secret and correct. But, given a choice between having balances revealed and having them altered, the first is preferable to the second. Integrity is more important than confidentiality.
In a typical UNIX system, protecting the integrity of system and user data can be a major challenge. There are many ways to alter and remove data, and often as little as a single bit change (like a protection bit or owner UID ) can result in the opportunity to make more widespread changes.
But ensuring integrity is difficult. Consider some of the ways that an unauthorized user could change or delete the file /usr/spaf/notes owned by user spaf :
And that is a partial list!
The goal of good integrity management is to prevent alterations to (or deletions of) data, to detect modifications or deletions if they occur, and to recover from alterations or deletions if they happen. In the next few sections, we'll present methods of attaining these goals.
Whenever possible, we would like to prevent unauthorized alteration or deletion of data on our systems. We can do so via software controls and some hardware means. We have discussed many of the software methods available on UNIX systems in other chapters. These have included setting appropriate permissions on files and directories, restricting access to the root account, and controlling access to remote services.
Unfortunately, no matter how vigilant we may be, bugs occur in software (more often than they should!), and configuration errors are made. In such cases, we desire that data be protected by something at a lower level - something in which we might have more confidence.
Two new mechanisms were built into the BSD 4.4 version of UNIX : the immutable and append-only files . These wonderful mechanisms are present only (at the time of this writing, to the best of our knowledge) in the Free BSD , Net BSD , and BSDI versions of UNIX . The fact that more commercial vendors have not seen fit to integrate this idea in their products is a pity.
As their names imply, immutable files are files that cannot be modified once the computer is running. They are ideally suited to system configuration files, such as /etc/rc and /etc/inetd.conf . Append-only files are files to which data can be appended, but in which existing data cannot be changed. They are ideally suited to log files.
To implement these new file types, BSD 4.4 introduced a new concept called the kernel security level . Briefly, the kernel security level defines four levels of security. Any process running as superuser can raise the security level, but only the init process (process number 1) can lower it. There are four security levels (see Table 9.1 ).:
The 4.4 BSD filesystem does not allow any changes to files that are immutable or append-only. Thus, even if an attacker obtains superuser access, he cannot modify these files. Furthermore, the system prevents "on-the-fly" patching of the operating system by making writes to the /dev/mem or /dev/kmem devices. Properly configured, these new innovations can dramatically improve a system's resistance to a determined attacker.
Of course, immutable files can be overcome by an attacker who has physical access to the computer: the attacker could simply reboot the computer in single-user mode, before the system switches into secure mode. However, if someone has physical access, that person could just as easily remove the disk and modify it on another computer system. In most environments, physical access can be restricted somewhat. If an attacker at a remote site shuts down the system, thus enabling writing of the partition, that attacker also shuts down any connection he would use to modify that partition.
Although these new filesystem structures are a great idea, it is still possible to modify data within immutable files if care is not taken. For instance, an attacker might compromise root and alter some of the programs used by the system during start-up. Thus, many files need to be protected with immutability if the system is to be used effectively.
A somewhat stronger preventive mechanism is to use hardware read-only protection of the data. To do so requires setting a physical write-protect switch on a disk drive or mounting the data using a CD-ROM . The material is then mounted using the software read-only option with the mount command. The best crackers in the business can't come across the network and write to a read-only CD-ROM !
If it is possible to structure the system to place all the commands, system libraries, system databases, and important directories on read-only media, the system can be made considerably safer. To modify one of these files, an unauthorized user would require physical access to the disk drive to reset the switch, and sufficient access to the system (physical access or operator privileges) to remount the partition. In many cases, this access can be severely restricted. Unmounting and remounting a disk would likely be noticed, too!
In those cases in which the owner needs to modify software or install updates, it should be a simple matter to shut down the system in an orderly manner and then make the necessary changes. As an added benefit, the additional effort required to make changes in a multiuser system might help deter spur-of-the-moment changes, or the installation of software that is too experimental in nature. (Of course, this whole mechanism would not be very helpful to a dedicated Linux hacker who may be making daily changes. As with any approach, it isn't for everyone.)
The way to organize a system to use read-only disks requires assistance from the vendor of the system. The vendor needs to structure the system so that the few system files that need to be modified on a frequent basis are located on a different partition from the system files that are to be protected. These special files include log files, /etc/motd , utmp , and other files that might need to be altered as part of regular operation (including, perhaps, /etc/passwd if your users change passwords or shells frequently). Most modern systems have symbolic links that can be used for this purpose. In fact, systems that support diskless workstations are often already configured in this manner: volatile files are symbolically linked to a location on a /var partition. This link allows the binaries to be mounted read-only from the server and shared by many clients.
There are some additional benefits to using read-only storage for system files. Besides the control over modification (friendly and otherwise) already noted, consider the following:
There are some drawbacks and limitations to read-only media, however: