System Administration: Maximizing Linux Security: Part 2

Last month's installment covered many aspects of password protection. This month's installment goes on to explain several other aspects of system security.
File-system Protection

Besides password protection, file ownerships and protection modes are the other major component of traditional UNIX security. Although far from a perfect solution, a carefully set up and maintained file-system will provide a great deal of protection from harm in the event that a non-root account is compromised. File-system security includes these considerations:

  • Correct ownerships and protections for system files: command binaries, shared libraries, and so on. Such files generally should be owned by root or another system user like bin and by a system group such as system or bin. They should not be group, or world, writable. Some files, such as the shadow password file, should be restricted to owner access only.

  • The same considerations apply to the directories where system files are stored. Keep in mind that write access to a directory allows you to modify any file within it regardless of the ownership or protections of the individual file (although SETGID access on a directory restricts users' access to their own files, as for /tmp).

  • SETUID and SETGID files deserve special scrutiny. They should be kept to a minimum and be thoroughly tested prior to installation. Any newly appearing SETUID root files should be regarded with extreme suspicion. The following command will locate all SETUID and SETGID files on the system:

    # find / -type f \
    \( -perm -2000 -o -perm -4000 \) -ls
  • User home directory trees should also contain no group, or world-writable subdirectories.

  • User login and shell configurations files—.login, .profile, .cshrc, and so on—should also be owned by each user and writable only by their owner.

  • Group memberships must be designed with care so that users are given access only to those files and directories they need.

  • Any tampering with system binaries, libraries, configuration files, and other vital data must be detected right away.

All of these can be summarized into just two overriding principles:

  • Know what normal is (and get your system to that state). This is made somewhat more difficult on Linux systems because there is considerable variation in system file ownership among the various distributions, so you will have to make some of those decisions yourself.

  • Make sure it stays that way by continuously monitoring it and performing regular backups.

The Tripwire facility from the COAST project at Purdue University can take care of the second step. Tripwire can record the correct state of the file-system and then, some time later, compare the current configuration with the saved one and report on any differences. It can consider external attributes of a file such as its ownership, protection, size, inode number (this would change if a file were replaced using standard UNIX commands), inode creation date, and file modification date.

However, since it is possible to modify a file without changing any of these items, Tripwire also calculates a number of file signatures for each file. In general, a file signature is a value computed using the contents of the file. Tripwire can compute file signatures using up to 10 different algorithms of varying complexity and corresponding difficulty in forging.

While it is possible to alter a file and still retain the same file signature for a single algorithm—in fact, it is relatively easy to do so for lower quality file signatures such as traditional checksums—altering a file without changing two or more different file signatures is a very hard problem indeed. When Tripwire checks the file-system, it can compare multiple file signatures for each file, thereby virtually ensuring that any alteration will be detected.

Tripwire has been ported to Linux, and it builds easily. After you have finished compiling the executables, it is important to run the test suite the package provides to ensure that everything is operating properly. The following command initiates the test suite:

# make test

To get started, you first run Tripwire in its initialization mode (tripwire -init). It is essential that you do so on a system known to be clean; ideally, Linux will have been reinstalled from the original media. In this mode, Tripwire creates a database listing the current attributes and file signatures you have requested for the files specified in its configuration file. During this initial run, you should compute as many different file signatures as you have CPU cycles to apply, including at least two different highly secure algorithms. You should also set up the configuration file to include as much of the system as possible, so you'll have data even for files you won't necessarily be watching on a regular basis should you ever need it.

The database will need to be similarly updated whenever an operating system upgrade occurs (given the rebuild rate for Linux kernels, that could be pretty often on some systems). Once the database is created, it must be stored in such a way that it cannot be tampered with under any circumstances (otherwise, a hacker could, for example, replace a file and also alter the information corresponding to it in the database). The Tripwire documentation suggests placing it on physically write-protected media, such as a locked diskette or removable disk, which is taken out of the drive when it is not in use. When the database is protected in this way, even changes made from a compromised root account can be detected. If possible, the Tripwire software itself should also be similarly protected.

After the initial database is created, Tripwire may be used to check the integrity of the file-system. How regularly you run Tripwire in this mode depends on the needs of your system and site, but I would recommend doing so nightly if at all possible. Figure 1 gives an example of the sort of report that Tripwire produces.

deleted: -rwxr-xr-x root  77828 Aug 23 22:45:43 1995
added:   -rwxr-xr-x root  10056 Mar 19 12:33:11 1995 /etc/
changed: -rwxr-xr-x root 155160 Apr 28 15:56:37 1995 /usr/bin/perl
### Attr        Observed (what it is)         Expected (what it should be)
### =========== ============================= =============================
st_size: 155160                        439400
st_mtime: Fri Feb 17 12:10:47 1995      Fri Apr 28 12:33:11 1995
md5 (sig1): 1Th46QB8YvkFTfiGzhhLsG        2MIGPzGWLxt6aEL.GXrbbM>

On this system, the executable for the refer command is missing, a new file (/etc/ has appeared (from Tripwire's point of view, anyway), and the executable for Perl has changed size, modification time, and file signature (computed with the MD5 algorithm). All these changes are important and should be investigated, although none of them conclusively indicates unauthorized activities (refer could have been deleted accidentally, /etc/ could have been created as a backup by a system administrator, and Perl could have been rebuilt since Tripwire's database was last updated).

Tripwire's configuration file (conventionally named tw.config) is very flexible and allows you to specify exactly what files and directories are checked and what attributes and/or file signatures are compared, in as much detail as you like.

Tripwire does an excellent job of monitoring the file-system for any changes. However, there are other system functions that also bear watching. The Computer Oracle and Password System (COPS) performs several useful tests of system security, and I recommend obtaining it and running it regularly. COPS is most useful for checking the following items:

  • The syntax and content of the password and group files.

  • Anonymous ftp setup.

  • User environments: umask values and PATH variable definitions as defined in users' login configuration files.

  • Searches for known-to-be-insecure versions of commands by comparing the dates of system executables with data from CERT advisories.

In addition to Tripwire and COPS, the following other facilities can be very useful for system security monitoring:

  • The /var/adm/sulog file, which contains records of each use of the su command (successful and unsuccessful). It should be examined regularly.

  • The syslog facility: many subsystems log messages via syslog. Its configuration file, /etc/syslog.conf, specifies what types of messages are recorded as well as their destination log file.

  • Data gathered by the optional accounting facility can be useful for some kinds of detective work. In order to use this subsystem, you will need to install the accounting and quota kernel patches, rebuild the kernel, and compile programs in the accounting utilities package.

The Computer Incident Advisory Capability (CIAC) has created the Merlin program as an easy-to-use graphical front end to several security monitoring packages including COPS, Crack and Tripwire.