COPS is structured as a dozen sub-programs invoked by a shell
script. That top-level script collects any output from the
subprograms and either mails the information to the local
administrator or else logs it to a file. A separate program that
checks for SUID files is usually run independently because of the
amount of time required for it to search through the filesystems. All
of the tools except the SUID checker are not meant to be run as
user root or any other privileged account.
Please note that the descriptions of the tools provided here do not
contain any detailed explanation of why the tools check what they do.
In most cases, the reason is obvious to anyone familiar with
UNIX. In those cases where it is not obvious, the bibliographic
material at the end of this paper may provide adequate explanations.
We apologize if the reasons are not explained to your satisfaction,
but we do not wish to provide detailed information for potential
system crackers who might have our system.
These are the individual the programs that comprise COPS:
- dir.check, file.chk
These two programs check a list of directories and files
(respectively) listed in a configuration file to ensure that they are
not world-writable. Typically, the files checked would include
/etc/passwd, /.profile, /etc/rc,
and other key files; directories
might include /, /bin, /usr/adm, /etc
and other critical
directories.
- pass.chk
This program searches for and detects poor password choices. This
includes passwords identical to the login or user name, some common
words, etc. This uses the standard library crypt routine,
although the system administrator can link in a faster version, if one
is available locally.
- group.chk, passwd.chk
These two tools check the password file (/etc/passwd
and
yppasswd
output, if applicable) and group file (
/etc/group
and
ypgroup
output, if applicable) for a variety of problems
including blank lines, null passwords, non-standard field entries,
non-root accounts with uid=0, and other common problems.
- cron.chk, rc.chk
These programs ensure that none of the files or programs that are run
by cron
or that are referenced in the
/etc/rc*
files are
world-writable. This protects against an attacker who might try to
modify any programs or data files that are run with root privileges at
the time of system startup. These routines extract file names from
the scripts and apply a check similar to that in file.chk.
- dev.chk
checks /dev/kmem, /dev/mem, and file systems listed in
/etc/fstab
for world read/writability. This prevents would-be
attackers from getting around file permissions and reading/writing
directly from the device or system memory.
- home.chk, user.chk
These programs check each user's home directory and initialization
files (.login, .cshrc, .profile, etc) for world writability.
- root.chk
This checks root startup files (e.g., /.login, /.profile) for
incorrect umask
settings and search paths containing the current
directory. This also examines /etc/hosts.equiv
for too much
accessibility, and a few miscellaneous other tests that do not fit
anywhere else.
- suid.chk
This program searches for changes in SUID file
status on a system. It needs to be run as user root for best results. This
is because it needs to find all SUID files on the machine, including
those that are in directories that are not generally accessible. It
uses its previous run as a reference for detecting new, deleted, or
changed SUID files.
- kuang
The U-Kuang expert system, originally written by Robert W. Baldwin of
MIT. This program checks to see if a given user (by default,
root) is compromisable, given that certain rules are true.
It is important to note once again that COPS does not attempt to
correct any potential security hazards that it finds, but rather
reports them to the administrator. The rationale for this is that is
that even though two sites may have the same underlying hardware and
version of UNIX, it does not mean that the administrators of
those sites will have the same security concerns. What is standard
policy at one site may be an unthinkable risk at another, depending
upon the nature of the work being done, the information stored on the
computer, and the users of the system. It also means that the COPS system
does not need to be run as a privileged user, and it is less likely to
be booby-trapped by a vandal.