摘要

  • COPS 把 Unix 中常见的弱口令、权限过宽和不安全启动文件，转化为可在本地主机重复运行的检查。
  • 这些可配置的小程序会报告潜在问题，却不会自行修复。多数检查无需 root；较完整的 SUID 文件搜索单独运行，并需要相应权限。
  • 没有告警的报告只说明当时启用了哪些检查、实际触及了什么，不能证明主机整体安全，也不能保证运行后状态不变。

反复出现的小问题

论文从一个务实观察开始：Unix 安全文献总在讨论相似的缺陷。SUID 程序、文件权限过宽、容易猜中的密码，往往在发现后并不难处理；真正费力的是在不断变化的系统里持续找出它们。Farmer 与 Spafford 想把这种检查变成可重复的工作。

COPS 是 “Computerized Oracle and Password System” 的缩写，但它不是网络扫描器。顶层 shell 脚本调用约十几个子程序，收集结果后邮件发送给本地管理员或写入文件。大多数组件使用 Bourne shell 和常见 Unix 工具，必要时辅以小型 C 程序；管理员可按本地需要调整或替换它们。

检查对象具体而有限：配置为所有人可写的文件和目录；与用户名相同或来自常见词汇的密码；账户和组文件格式异常；cron 或启动脚本会调用的可写文件；部分设备权限；用户主目录和初始化文件；root 启动项中的 umask 与包含当前目录的搜索路径。suidchk 将当前 SUID 文件集合与先前运行结果比较。规则系统 Kuang 则检查依照其规则，某个用户是否可能走到目标账户被攻破的状态。

这种清单比“扫描安全性”更能说明 COPS 的作用：它降低了反复运行一组本地检查的成本，但不覆盖所有缺陷，也不负责判断每项权限是否违背某个站点的政策。

发现问题后仍由人决定

作者有意让 COPS 报告问题，而不修改主机。硬件与 Unix 版本相似的两套系统，也可能承载不同业务、数据和访问需要。一处能接受的设置，在另一处可能完全不可接受。自动修复会把技术发现变成政策决定，而程序并不掌握作出决定所需的上下文。

权限安排也体现了这种克制。论文指出，除 SUID 搜索外，其他工具不应以 root 等特权账号运行。SUID 搜索通常单独执行，因为它耗时较长，还需要进入普通账号无权访问的目录。因此日常检查所需权限较低，但每份报告的实际覆盖范围取决于各组件如何启动。

论文建议借助 at 或 cron 定期运行：今天尚未出现的问题，之后仍可能产生。定时执行不等于检查完整。程序或路径清单遭到更改，可能给出误导性结果；攻击者也可能读取报告或改动工具；长期没有告警还可能让管理员放松警惕。系统运行方式变化时，旧检查之外也可能出现新弱点。

证据的边界

Farmer 与 Spafford 收到来自高校、政府和企业站点的反馈。他们称，在测试过或收到相关报告的系统中，超过一半出现了可能导致 root 被攻破的条件；但也说明，无法判断这一有限观察能否推广到更大范围。它不是所有 Unix 系统的风险统计。

COPS 与 Farmer 后来的 SATAN 面向不同表面：前者检查本机账户、文件、权限和启动配置；后者检查网络服务及其他主机可见的暴露。作者相同不代表两类报告可互换。

Heng Lu 的 Note 65 在此仅作编辑视角：对运行中系统的结论，不应超出实际执行所观察到的范围。落实到 COPS，就是查明哪些程序运行过、拥有什么权限、触及哪些路径、运行于何时。自动化能让清单重复执行；检查范围、报告保密、结果解释和修复决策仍需管理员承担。

来源