 | Chapter 9 |  |
| Chapter 9 | |
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:
"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. 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:
Permissions on notes allow modification by other users.
Someone is able to compromise the login password of user spaf.
Someone is able to compromise user root.
setuid programs to root or to spaf allow the file to be altered.
Permissions on one of the directories /, /usr, or /usr/spaf allow the file to be deleted.
Permissions can also allow the file /usr/spaf/notes to be moved and a new file created in its place. The new file would have ownership and permissions based on who created it. In a sense, the original file would not have been deleted, but only renamed.
Permissions for the group "owner" of the file or one of the containing directories allow another user to modify it.
/etc/passwd can be altered by an unauthorized user, allowing someone to become root or user spaf.
The block device representing the disk containing the file can be written to by an unprivileged user.
The raw device representing the disk containing the file can be written to by an unprivileged user.
The directory is exported using some network filesystem that can be compromised and written to by an external host.
Buggy software allows the file to be altered by an unauthorized user.
Permissions on a system binary allow an unauthorized individual to plant a Trojan Horse or virus that modifies the file.
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.[1] In such cases, we desire that data be protected by something at a lower level - something in which we might have more confidence.
[1] In a presentation by Professor Matt Bishop of UC Davis, he concluded that as many as 95% of reported UNIX security incidents that he studied might be the results of misconfiguration!
Two new mechanisms were built into the BSD 4.4 version of UNIX: the immutableand append-only files. These wonderful mechanisms are present only (at the time of this writing, to the best of our knowledge) in the FreeBSD, NetBSD, 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).:
Security Level | Mode | Meaning |
|---|---|---|
-1 | Permanently insecure | Normal UNIX behavior |
0 | Insecure mode | Immutable and append-only flags can be changed. |
1 | Secure mode | The immutable and append-only flags cannot be changed. UNIX devices that correspond to mounted filesystems, as well as the /dev/mem and /dev/kmem devices, are read-only. |
2 | Highly secure mode | A superset of the secure mode. All disk devices are read-only, whether or not they correspond to mounted filesystems. This prevents an attacker from unmounting a filesystem to modify the raw bits on the device, but it prevents you from creating new filesystems with the newfs command while the system is operational. |
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!
NOTE: The read-only option to the mount command does not protect data! Disks mounted with the read-only option can still be written to using the raw device interface to the disk - the option only protects access to the files via the block device interface. Furthermore, an attacker who has gained the appropriate privileges (e.g., root) can always remount the disk read/write.
The existence of the read-only option to the mountcommand is largely for when a physically protected disk is mounted read-only; without the option, UNIX would attempt to modify the "last access" times of files and directories as they were read, which would lead to many error messages.
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:
You only need to do backups of the read-only partitions once after each change - there is no need to waste time or tapes performing daily or weekly backups
In a large organization, you can put a "standard" set of binaries up on a network file server - or cut a "standard" CD-ROM to be used by all the systems making configuration management and portability much simpler
There is no need to set disk quotas on these partitions, as the contents will not grow except in well-understood (and monitored) ways
There is no need to run periodic file clean or scan operations on these disks as the contents will not change
There are some drawbacks and limitations to read-only media, however:
This media is difficult to employ for user data protection. Usually, user data is too volatile for read-only media. Furthermore, it would require that the system administrator shut down the system each time a user wanted to make a change. This requirement would not work well in a multiuser environment.
Few vendors supply disks capable of operating in this mode as a matter of course. Most disks in workstations are internal, and do not have a write-protect switch.
It requires that an entire disk be made read-only.[2] There may be a large amount of wasted space on the disk.
[2] Some disks allow only a range of sectors to be protected, but these are not the norm.
This media requires at least two physical disks per machine (unless you import network partitions) - the read-only disk for system files, and a disk for user files.
If you are operating from a CD-ROM disk, these may have slower access times than a standard internal read/write disk.
|  | |
| 8.8 Administrative Techniques for Conventional Passwords |  | 9.2 Detecting Change |