20.2 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. In such cases, we want our data
to be protected by something at a lower level—something in
which we might have more confidence.
20.2.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.
184.108.40.206 The chflags command
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
# 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!
220.127.116.11 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.
Table 20-1. BSD 4.4 security levels
Normal Unix behavior.
The immutable and append-only flags can be changed.
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.
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
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
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.
20.2.2 Read-Only Filesystems
somewhat stronger preventive
mechanism is to use hardware read-only
protection of the data. To do so requires setting a
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!
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
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
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
There is no need to set disk quotas on these partitions, as the
contents will not grow except in well-understood (and monitored)
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
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.
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