June 26, 2011, 10:46 a.m.
posted by sussel
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 want our data to be protected by something at a lower level—something in which we might have more confidence.
1 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 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.
1.1 The chflags command
The superuser can make any file immutable or append-only through the use of the chflags command. 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!
1.2 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 Figure. Any process running as superuser can raise the security level, but only the init process (process number 1) can lower it.
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.
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.
2 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 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!
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:
There are some drawbacks and limitations to read-only media, however: