Protecting Integrity

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.^[297] In such cases, we want our data to be protected by something at a lower level—something in which we might have more confidence.

Immutable and Append-Only Files

Two helpful mechanisms were built into BSD 4.4 Unix: immutable files and 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, OpenBSD, BSDOS, and Linux^[298] versions of Unix. It is a pity that more commercial vendors have not seen fit to integrate these ideas in their products.

As their name implies, 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, as well as for the Unix kernel itself. Append-only files are files to which data can be appended, but in which existing data cannot be changed. They are ideally suited for log files.

The chflags command

The superuser can make any file immutable or append-only through the use of the chflags command.^[299] This example makes the kernel immutable and the file /var/log/messages append-only:

# chflags schg /kernel
# chflags sappnd /var/log/messages

Now even the superuser cannot change the contents of these files (although the superuser can still append to /var/log/messages). Attempts to modify the contents give a suitable error message:

# /bin/rm /kernel
override r-xr-xr-x  root/wheel schg for /kernel? y
rm: /kernel: Operation not permitted
#

You can verify the flags on a file using the -o option to the ls command:

# ls -l -o messages
-rw-r--r--  1 root  wheel  uappnd 118506 Aug 17 22:15 messages
# chflags nouappnd messages

Of course, the superuser can remove the flags:

# chflags noschg /kernel 
# chflags nosappnd /var/log/messages
# ls -l -o messages
-rw-r--r--  1 root  wheel  - 118608 Aug 17 22:16 messages
#

Now you can delete your kernel, if you really want to!

Kernel security level

To implement these new file modes, BSD 4.4 introduced a new concept called the kernel security level. Briefly, the kernel security level defines the four levels of security listed in Table 20-1. Any process running as superuser can raise the security level, but only the init process (process number 1) can lower it.^[300]

Table 20-1. BSD 4.4 security levels

Security level	Mode	Meaning
-1	Permanently unsecure	Normal Unix behavior.
0	Unsecure mode	The 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. By including init and its configuration files in the set of immutable files, the attacker is prevented from remotely rebooting the system at a lower security level. 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.^[301]

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 startup. Thus, many files need to be protected with immutability if the system is to be used effectively.

Read-Only Filesystems

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^[302] or mounting the data using a CD-ROM or DVD. The material is then mounted using the software read-only option with the mount command. Even the best computer criminals in the business can’t connect 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 protects only 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 mount command 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 will 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 need to do backups of the read-only partitions only 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.
Many operating systems will not operate properly from read-only media. Although most will boot from read-only media, but usually this option is only for installation or diagnostics.
Few hardware vendors supply disks with hardware write protection.
Using read-only media means that most computers will require at least two physical disks (unless you import network partitions), further increasing costs.
CD-ROM and DVD drives are dramatically slower than standard magnetic read/write media. As a result, many systems will not perform well when running these devices.

Read-Only Unix

What use is a Unix system if you can’t write anything to disk? Sometimes, it’s very useful indeed, as shown by the popularity of floppy-only or CD-ROM-only firewall distributions of Linux and FreeBSD.

These distributions boot from either a write-protected floppy disk or a CD-ROM, and load the operating system entirely into memory using a RAM disk. If an attacker should manage to subvert the system, he may be able to breach the firewall, but he can make no permanent changes to it; a simple reboot restores the system to its pristine (vulnerabilities and all) condition. Moreover, these distributions are usually very small, with few points of attack.

Floppy-based distributions can be changed or upgraded by mounting the floppy without write protection on a secure internal system; CD-ROM distributions often use a write-protected floppy to store volatile configuration information, and this floppy can be changed in a similar fashion.

^[297]In one presentation by Professor Matt Bishop of UC Davis, he concluded that as many as 95% of reported Unix security incidents that he studied might have been the results of misconfiguration!

^[298]When using the ext2fs or ext3fs filesystems; other filesystems may not support the immutable and append-only attributes.

^[299]In Linux, the chattr command is used to modify these flags.

^[300]And init only lowers it when the system is shutting down.

^[301]As of the Linux kernel 2.4.18, however, Linux typically does not implement kernel security levels. Thus, although the superuser can set a file as immutable or append-only, an attacker who gains superuser privileges can simply unset these attributes. There are kernel patches that can make this more difficult by restricting the kernel capabilities that root has access to, but they are not as complete as the BSD approach.

^[302]For years and years, all disk drives came with write-protect switches. In the 1980s, these switches slowly started disappearing from disk drives, and by the 1990s they had all but vanished because of the added cost in equipping systems with an extra piece of hardware. Now, in the 21st century, write-protect switches are beginning to return to disk drive systems because of the security that they provide.

Previous Chapter

The Need for Integrity

Next Chapter

Detecting Changes After the Fact