Linuxディストリビューションの安全性が確立されるまでの舞台裏
メジャーなディストリビューションであれば、どのようなベンダであっても、セキュリティチームを組織し、メインのリリースチームとの協力の下、ファイナルリリースの公開時までに不安定なパッケージが残存していないことを確認させているはずである。例えばGentooの場合、リリースエンジニアリングに関する戦略リーダを務めるChris Gianelloni氏によると、リリースエンジニアリングチームがセキュリティチームおよび各種のアーキテクチャチームと共同して、Gentooのリリース時にセキュリティ上の脆弱性が残っていないかを確認しているとのことだ。
ディストリビューションごとに異なる手法
脆弱性のあるパッケージの確認と一口に言っても、その手法は個々のディストリビューションごとに異なっているのが普通である。例えばDebianのMoritz Muehlenhoff氏によると、同ディストリビューションの場合はSecurity Trackerによって開発チームからレポートされるバグを追跡し、それと併せてNational Vulnerability Database（NVD）なども情報源として参照しているとのことだ。
またRed Hatのセキュリティ対策チームに属するMark Cox氏の説明では、「新規リリースを準備する際には、セキュリティ対策チームがリリース用のパッケージを監査し、脆弱性の残留箇所を可能な限り少なくするよう努めています」とされている。
Red Hatの場合、複数のテストツールと独自の回帰テストを組み合わせることで、問題点の検出を行っているとのことだ。「私どもの場合、新規に登場するセキュリティ上の脆弱性を常に把握するよう努めておりますが、そうした問題については従来とは異なるセキュリティ管理法を実践する必要があります。例えば製品として用いるすべてのパッケージに対してコンパイル時に施しているのが、Exec Shield、FORTIFY_SOURCE、スタックプロテクタなど複数のセキュリティ関連テクノロジを用いた監査です。こうしたテクノロジのいくつかは、プログラミングミスに起因するセキュリティ上の脆弱性をコンパイル段階で検出する能力を有しています」とCox氏は説明する。
それでは実際に新たな脆弱性が発見された場合、具体的にどのような措置が施されているのか？ DebianのセキュリティFAQにある説明によると、Debianの場合は「セキュリティチームに報告が届くと、1ないし複数のメンバによる評価が行われ、安定版のDebianリリースに対する影響が検討されます（対処すべき脆弱性であるかなど）。そして、システムの脆弱性であることが確認されると、問題箇所の修正が行われます。セキュリティチームとの連絡が取れていないパッケージメンテナについても同様の措置が執られます。最終的には、修正部分のテストを施した後、新規パッケージを準備し、安全が確認されたすべてのアーキテクチャに対するコンパイルが行われた後でアップロードされます。これらすべての手順を経た後、修正点に関する告知が行われます」という旨の説明がされている。
NovellにてLinuxセキュリティ問題を担当するRoman Drahtmueller氏によると、脆弱性の特定と修正とは終わることのないプロセスであり、同社の製品のセキュリティを高める上で常に行い続ける必要のある性質の作業だとされている。「Novellの製品については、確認済みの重大な脆弱性を残したままリリースされることはありません。ただしマスタの作成日からカスタマによるインストールまでの間に、深刻度において中程度の脆弱性が新たに確認されるということは考えられます。それ故リリース直後の製品であっても当該インストレーションに対するアップデートが用意されているケースもありますが、その数は最小限に止まっているはずです」。
Drahtmueller氏が補足するところによると、現行の基本方針として、セキュリティ上の脆弱部に対するオペレーティングシステムの感受性を将来的に減少させていくゆく方向で開発を進めるようにしているとのことだ。「その他にも、ソフトウェア構成管理システム中のコードベースを改変する際には、不用意な変更が混入することがないよう、常に複数のスタッフによる確認が行われています。これに関係するパッチの配布やチェックインのポリシなどすべてのプロセスは、SUSEが3年がかりで構築してきた情報セキュリティ国際評価基準（Common Criteria）の一環として検討されたものです」。
それでは、Red Hat Enterprise Linuxとのバイナリ互換性100％を目指しているCentOSの場合はどうなのか？ CentOSの主任開発者を務めるJohnny Hughes氏の説明によると、「私どもの場合は、アップストリーム側で変更されない限り、リポジトリのアップデートやベースパッケージの変更をしないでくれという要請が、ユーザ側から出されています」とのことである。
ただし、脆弱性ないしバグが確認された場合のパッチないしアップデートのリクエストについては、一般に公開されているバグ追跡システムを介してアップストリーム側に提出されるということだ。ExtrasおよびCentOSPlusリポジトリにあるパッケージのリビルドについても同様で、アップストリーム側のパッケージ作成者に対してパッチ作成を要請するという措置が執られている。
「SRPMS用に構築するアイテムに関しては、個々のパッケージに対して1人の開発者が任命され、その開発者がソースファイルのプロバイダとの連絡を取るようにしています（通常はメーリングリストを使用）。これらのケースにおいても、通常はプログラムプロバイダが別途存在し、彼らの手によりSRPMS/RPMS以外の形式による一般的なパッケージ提供が行われるようになっています。基本的な手順として、問題の発生したファイルについては、担当メンテナに対してフィードバックや推奨パッチを提供し、メンテナが必要な変更を実装した後で、変更結果を取り込むという流れになっています」とHughes氏は説明する。
リリース後のディストリビューションに対する安全性の確立
このようにディストリビューションをリリースする際には、既知の脆弱性をすべて取り除いておくための多大な努力が払われている。しかし、問題はそれだけだろうか？ いったんリリースしたディストリビューションに対しては、セキュリティは考慮する必要はないのだろうか？ 当然、その様なケースについても対策を執らなければならない。
Debianの場合は、Security Trackerによってリリース後に確認される問題を追跡しているという。またMuehlenhoff氏の示唆するところでは、こうした問題に神経質なユーザの中にはdebsecanというツールをわざわざインストールして、特定のシステム中に存在する脆弱性を逐次報告してくれる者がいるそうだ。
CentOSチームの場合は、Hughes氏によると、セキュリティに関する問題をいくつかのリストにまとめており、オフィシャルのパッケージメンテナからリリースされるパッチを速やかに公開できる体制を維持しているとのことである。
Gentooの場合は、セキュリティに関するアナウンスと共に、関連パッケージにおける脆弱性を緩和する手順も解説するようにしている。Gianelloni氏が指摘しているのは、GentooのPortageツリーは動的な変更を受ける性質のシステムであるため、アップデートもこうしたツリーそのものに対して施されるという点だ。つまりPortageツリーを同期させてから個々のパッケージをアップグレードすれば、セキュリティについては最新の状態に維持しておくことができる、というのである。またGentooの公開しているセキュリティ関連ドキュメントによると、セキュリティのみのアップデートをPortageツールに統合する計画が進行中とのことだ。
Red Hatの場合、Cox氏の説明によると、エンタープライズディストリビューションに移行する一環として、同社製品に対する署名管理システムによるセキュアな自動アップデート機構を2000年より採用しており、必要なアップデートを速やかに入手できるようにすることで、脆弱性その他の脅威におけるカスタマ側の負担を軽減させるべく配慮しているとのことだ。「私どもが採用した革新的なセキュリティ対策の特長は、製品リリース後に脆弱性が確認される場合において、それらの深刻度を引き下げる方向に寄与するようデザインされていることです。例えばRed Hat Enterprise Linux 4で言うと、危険度の高いサービスを保護するためのポリシを準備した上で、デフォルトでSELinuxが機能するよう設定されています。こうした措置は、脅威に対抗してシステムを場当たり式に強化してゆくよりも、設定可能なセキュリティ機能はデフォルトで有効にしてゆく方がよい、という基本方針に則ったものです」と同氏は補足している。
Red Hat Enterprise Linuxのセキュリティガイドを見ると、セキュリティに関するベストプラクティスが詳しく説明されている。その他にCox氏が言及しているのは、ユーザが遭遇するであろう脆弱性と脅威のレベルを適時公開しているセキュリティレポートの存在だ。
Novellの場合、Drahtmueller氏によると、そのセキュリティチームは「Novell製品全般に関する様々なセキュリティ問題を扱っていて、障害の報告者についての初期対応を始め、他のベンダおよびセキュリティ関連組織との連絡、当該ソフトウェアに対する社内での技術的および組織的な管理活動を担当しており、これらの活動は最終的にユーザの利益として還元できる段階に達するまで継続します」とのことだ。
アップデートをインストールするのはセキュリティ上の基本であるが、Drahtmueller氏によると、セキュリティを重要視するユーザであれば、有用な関連情報と「追加的措置および基本対策」へのリンクがまとめられたNovellのセキュリティページも参照するべきだとのことである。
Drahtmueller氏は、AppArmorというNovellのセキュリティ製品についても言及している。「セキュリティ上の脆弱性が対策されていない状況下でシステムを運用し続けなければならないケースもありますが、AppArmorとは、そうした脅威の及ぶ範囲を局限化することでカスタマのIT資産を守るというコンセプトのテクノロジです。AppArmorには、Novellシステムでの使用頻度が高いサービスに関する様々なプロファイルが事前定義されており、最近の製品であればデフォルトで機能するよう設定されています。オリジナルの製品にバンドルされていないサービスやアプリケーションであっても、AppArmorを用いることでセキュリティが高まるものが存在する場合は、AppArmorの付属ツールを用いることで、プロファイルの作成と移植が簡単に行えます」。
時間を要する性質のプロセス
これまでの説明からも分かるように、ディストリビューションを継続的にリリースしてその安全性を確保してゆくのは生半可な仕事ではない。だが、具体的にどの程度の人手と時間を必要とするのだろうか？ 私も実際にセキュアなディストリビューションの維持に要する手間を調べて初めて知ったのだが、そうしたプロセスに携わる人員と費やされる時間は驚くべき量に上るのである。例えばCentOSの場合、13名の開発者全員がセキュリティチームに名を連ねている。「私の試算によると、CentOSの開発時間の25から30％はセキュリティに直接関連する作業ないし製品のセキュリティアップデートに費やされているはずです」とHughes氏は語る。
Debianの場合、Muehlenhoff氏によると、セキュリティチームは総勢6名で構成されているそうだ。ただし作業の性質上、セキュリティチームの仕事は開発サイクルに一体化されているため、どの程度の作業時間がセキュリティ関連の問題にのみ費やされているかを正確に単離するのは難しいと言う。「純粋に分からない、というのが正直なところです。なにしろ、チェック作業には非常に多数の人間が関与しており、Debianのメンテナだけでも1,000名を越えているくらいですから。信頼できる情報源からの報告ならチェック作業は5分で済むでしょうが、XFree86のような巨大パッケージともなると一通りの評価だけで数時間がかりになる場合もあります」。
Gentooのセキュリティチームは11人体制だが、何人かは実際の活動はしていないという。Gianelloni氏の説明によると、やはりセキュリティ関連の問題だけの作業時間という数値を算定するのは無理だが、1つのリリースを仕上げるには2から3カ月を要するということだ。
「これは一般論ですが、私どもの場合、最初の1から2カ月を新規リリースで用いるパッケージについての予備的な品質検査に当てています。パッケージにバグがないかを確認し、存在すればその対策を行いますが、同様の作業はリリースのビルド用ツールに対しても実施しなければなりません。その後パッケージリポジトリのスナップショットを作成してから、リリースビルドの構築を開始します。ビルド過程では、新規のビルドおよびセキュリティに関する問題が生じてくるので、それを解決するための調整をパッケージに施すことになります」。
Novellの場合、Drahtmueller氏によると、そのセキュリティ対策プロセスでは、具体的なパッチ作成、アップデートパッケージの試験および品質検査、最終的なリリースおよび関連情報のアナウンスなどに多数の開発者が関与している、ということである。「平均的なパッケージで言えば、最大で21名の人員が参加することがあります。セキュリティチームは4名で構成され、作業の開始、監督、必要な場合はアップデート作業プロセスの修正、そして最終的に正式なアナウンスを行うタイミングの管理を受け持ちます」。
こうしたプロセスに要する時間について問い合わせたところ、同氏からは「製品の新規リリースにおける通常の統合作業で行われる修正と比べると、セキュリティ上の脆弱性に関する作業はより多くのリソースを消費します。その理由としては、この種の問題は本質的に最優先の課題として処理しておく必要があると同時に、プロジェクトの開発計画とは無関係に出現する性質であることが挙げられます。またセキュリティに関係するソフトウェア的な不備が存在すると、それに起因してどのような影響が生じるかは一概に予想し得るものではなく、開発元でさえ予想不可能なダメージを及ぼす可能性を常に秘めています。有効な対策として行えることは、投入する時間を最小限に抑えつつも、ベストエフォットによる対策努力を施しておくのが精々といったところですね」という回答が返された。
Red Hatの場合は、Cox氏によると、複数のセキュリティチームを組織して、それぞれが個別のセキュリティ問題を専門に担当しているとのことだ。「私どものセキュリティ対策チームはリリース後に確認される脆弱性に対処することを仕事としており、それぞれの国ごとに人員を配置することで全世界で生じうる問題をカバーするようにしています。特に危険度の高い脆弱性については、迅速な問題解決を試みられるよう、セキュリティチームが他の部門から必要なスタッフを招集できるようにしてあります」。
「その他にも、SELinux、各種のセキュリティ関連技術、機密保護証明などを担当するチームが組織されています。いずれの作業も1つのプロセスを構成する要素という点はほぼ共通していますが、セキュリティ対策チームによる監査について言えば、非常に長いスパンをかけてリリースサイクルの終了までに完遂させるのがその特色だということになるでしょう」。
まとめ
セキュアなディストリビューションを構築するという作業は、言葉にしてしまうと非常に簡単に感じられるかもしれないが、その確立までにメジャーなベンダが投入している手間と時間と努力は並大抵のものではない。リリース製品のバンドルアプリケーションに脆弱性やバグが残存していないことを保証するためには、多数の開発者が協力してその作業に当たる必要がある。セキュリティ関連の問題はリリース後に新たに生じることもあり、特殊な専用ツール、セキュリティ関連の報告書、入念なパッケージ監査といった手法を最大限に活用することで、ディストリビューションの安全性は維持されているのである。
