要約

  • COPSは弱いパスワード、過度に開かれた権限、危険な起動ファイルといったUnixの既知の問題を、ローカルホストで繰り返し確認できるようにした。
  • 構成可能な小さなプログラム群は問題の可能性を報告するが、自動修正はしない。大半はroot権限を必要とせず、SUIDファイルの広範な検索は分けて実行された。
  • 警告がない結果は、設定された検査がその時点で到達した範囲を示す。ホスト全体の安全性や、実行後に状態が変わっていないことの証明ではない。

ありふれた問題を繰り返し探す

1990年の論文は、Unixのセキュリティ文献で同じ問題が何度も取り上げられていたという観察から始まる。SUIDプログラム、緩すぎるファイル権限、弱いパスワードは、発見後の修正自体は簡単な場合が多い。難しいのは、変化する環境で見落とさず探し続けることだった。FarmerとSpaffordは、その点検を反復可能にしようとした。

COPSは“Computerized Oracle and Password System”の略だが、ネットワークスキャナーではない。最上位のシェルスクリプトが十数個ほどの小さなプログラムを呼び出し、結果をまとめて管理者へメールするかファイルに記録する。多くはBourne shellと一般的なUnixコマンドで構成され、必要な部分には小さなCプログラムが使われた。各部品は導入先に合わせて変更や交換ができた。

対象は具体的な管理項目だった。誰でも書き込める設定済みのファイルやディレクトリ、ユーザー名と同じか一般語を使うパスワード、アカウントやグループ情報の形式異常、cronや起動スクリプトから実行される書き換え可能なファイル、特定デバイスの権限、ホームディレクトリと初期化ファイルを調べた。rootの起動設定では、不適切なumaskやカレントディレクトリを含む検索パスも確認した。suidchkはSUIDファイルの現在の状態を前回と比較し、Kuangはルールに基づきユーザーから対象アカウント侵害に至る可能性を調べた。

COPSの価値は、定義済みのローカル検査を繰り返す負担を下げたことにある。「安全性全体をスキャン」したわけではなく、すべての問題を網羅したり、各設定が個別サイトの方針に反するかを判断したりもしなかった。

検査結果を修正命令にしなかった

作者はCOPSがホストを変更しない設計を選んだ。同じハードウェアとUnixの版でも、サイトごとに仕事、データ、必要なアクセスは異なる。一方で許される設定が、別の環境では許容できないかもしれない。自動修正は、プログラムが知らない背景を必要とする方針判断を代行してしまう。

権限の扱いも同じ考え方だった。論文によれば、SUID検索以外はrootなどの特権アカウントで動かす想定ではない。SUID検索は時間がかかり、通常の利用者が入れないディレクトリまで調べるため、別に実行されることが多かった。通常の確認に必要な権限は抑えられるが、報告の範囲は各部品の起動方法に左右された。

論文はatやcronによる定期実行を勧める。今日見つからない問題が後日生じる場合があるからだ。しかし定期実行は網羅性を保証しない。設定や検査パスが変更されれば結果は誤解を招き得る。報告を攻撃者に読まれること、検査ツールが改変されること、警告のない結果が続いて油断することも作者は懸念していた。システムの運用方法が変われば、既存の検査が対象にしない欠陥も現れ得る。

記録が支える主張

作者は大学、政府、企業から利用者の反応を受けた。検査した、または報告を受けたシステムの半数超にroot侵害につながり得る問題があったと記した一方、その限られた観察をより大きな母集団へ一般化できるかは不明とした。すべてのUnixシステムについての割合ではない。

後のSATANとは観測面が異なる。COPSはローカルなアカウント、ファイル、権限、起動設定を調べ、SATANはネットワークサービスと他のホストから見える露出を扱った。同じ人物が関わったことは、報告の意味が同じである証拠にはならない。

Heng LuのNote 65は編集上の視点としてのみ使う。稼働中のシステムについての結論を、実際の検査が観測した範囲より広げないという考え方だ。COPSなら、どの検査がどの権限でどのパスに対していつ実行されたかを確認する。自動化は再実行を容易にするが、範囲、報告の保護、解釈、修正の判断は管理者に残る。

出典