Summary

  • COPS turned familiar Unix weaknesses—weak passwords, exposed permissions and unsafe startup files—into checks that could be repeated on a local host.
  • Its configurable programs reported possible problems but did not repair them. Most did not need root; the broader SUID-file search was separate and required privilege for better coverage.
  • A clean report described the configured checks and what they reached at that moment. It did not certify complete security or guarantee that the host stayed unchanged.

The recurring faults were the point

The 1990 paper starts with a practical observation: Unix security writing kept returning to the same faults. Set-user-ID programs, permissive file modes and weak passwords were often simple to correct once found. The hard part was finding them again as installations changed. Farmer and Spafford proposed making that inspection routine.

COPS—“Computerized Oracle and Password System”—was not a network scanner. A top-level shell script gathered output from roughly a dozen subprograms and mailed it to the local administrator or logged it to a file. Most components used Bourne shell and common Unix commands; small C programs filled specific gaps. The pieces could be reconfigured or replaced for a site’s needs.

The checks were concrete: world-writable files and directories listed in configuration; passwords matching a user name or common words; malformed account and group records; writable files called by cron or startup scripts; selected device permissions; home directories and initialization files; root startup umask and search paths containing the current directory. suidchk compared the current SUID-file set with an earlier run. Kuang used rules to examine whether a user could reach a compromised-account condition.

That scope is more revealing than calling COPS a security scanner. It reduced the cost of repeating a known set of local checks; it did not cover every flaw or decide whether every permission violated a site’s policy.

The tool stopped before repair

The authors deliberately had COPS report rather than alter the host. Two installations with similar hardware and Unix versions may handle different work, data and access needs. An acceptable setting at one site may be intolerable at another. Automatic correction would turn a technical finding into a policy decision the program lacked context to make.

The same restraint shaped privilege. The paper says checks other than the SUID search were not intended to run as root. The SUID search was usually separate: it could take longer and needed access to directories unavailable to ordinary users. Routine inspection therefore required less privilege, but the report’s reach depended on how each component was run.

The paper recommends recurring runs with at or cron, since a condition absent today could arise later. Scheduling was not completeness. A changed checker or path list could make its output misleading; an attacker might read reports or modify the tool; repeated clean runs could breed complacency. The authors also warned that changes in system operation could create weaknesses outside existing checks.

What the evidence supports

Farmer and Spafford reported feedback from academic, government and commercial sites. More than half of the systems they had tested or heard about showed conditions that could compromise root, they wrote, but they could not generalize that limited observation to a larger population. It is not a prevalence estimate for Unix systems.

COPS and Farmer’s later SATAN work addressed different surfaces. COPS checked local accounts, files, permissions and startup configuration; SATAN examined network services and exposure visible from other hosts. The shared author does not make their reports interchangeable.

Heng Lu’s Note 65 is an editorial lens only: claims about a running system should not exceed what the executed checks observed. For COPS, ask which checks ran, with what access, against which paths and when. Automation makes a checklist repeatable; an operator still has to define scope, protect output, interpret findings and choose repairs.

Sources