20.1 The Need for Integrity

Why the lack of interest in integrity? In part, we believe that this is 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, the primary goal is to prevent unauthorized personnel from reading sensitive data. This is called confidentiality and is of paramount importance in the military view of computer security.

Confidentiality is a priority that's easy to understand, but it can be weird in practice. It leads us to security policies that say it is acceptable, at some level, to blow up the computer center, burn the backup tapes, and kill all the users—provided that the datafiles are not read by an attacker! (The "self-destruct" system of Star Trek's USS Enterprise was designed with this kind of confidentiality in mind.)

We believe that in most commercial and research environments, the often ignored goal of integrity is actually more important than confidentiality or availability. If integrity were not the priority, the following scenarios might actually seem reasonable:

Well, whoever came in over the Net wiped out all of /usr and /etc, but they weren't able to read any of the files in /tmp. I guess our security worked!

or:

Somebody compromised the root account and added 15 new users to /etc/passwd, but our security system kept them from doing an ls of the /usr/spool/mail directory. We dodged a bullet on this one!

or:

As near as we can tell, one of the people we fired last week planted a virus in the system that has added itself to every system binary, and the virus is causing the system to crash every 15 minutes. We don't have a security problem, though, because we have shut off the network connection to the outside, so nobody will know about it.

These examples are obviously silly in most settings. Clearly, we are concerned 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 frequently 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 changed bit (such as a protection bit or owner UID) can result in the opportunity to make more widespread changes.

But ensuring integrity is difficult. Consider the example of a malicious user who attempts to change or delete the file /usr/spaf/notes owned by user spaf. It seems that there are all too many ways that the attacker could accomplish this goal:

The permissions on the file notes could be changed to 666, allowing the file to be modified by any user on the system.
The user spaf's account could be compromised by someone who learned spaf's password (perhaps because spaf used the same password at a web site).
The superuser account could be compromised.
An attacker could use buggy setuid programs running as root or as spaf to access the file.
Permissions on one of the directories /, /usr, or /usr/spaf could be modified to allow the file to be deleted.
Permissions on the directory /usr/spaf could allow the file to be moved and a new file created in its place. The new file would have ownership and permissions based on who created it.
Permissions on the file /etc/passwd and /etc/shadow might not be properly set and might allow someone to directly change the password of root or user spaf, and then to log into one of those accounts.
The permissions might be inappropriately set on the block device corresponding to the disk containing the file, allowing an unprivileged user to directly write to the disk and change the file's contents.
The directory in which the file resides might be exported using some network filesystem that could be compromised and written to by an external host.
A virus or Trojan horse might be planted on the system that specifically targeted the user spaf. This program would wait until spaf runs it, and then modify the file. When other users run the virus, it might do nothing.

And this is only a partial list!

The goal of good integrity management is to prevent alterations to (or deletions of) data, detect modifications or deletions if they occur, and recover from alterations or deletions if they happen. In the next few sections, we'll present methods of attaining these goals.