セキュリティーウォッチチームの作業

セキュリティーウォッチチームでは、以下のような作業を行っています。

• セキュリティ情報を発見・収集
• セキュリティ情報を Security BTS に登録
• 対策済みパッケージの作成
• 対策済みパッケージのテスト
• errata 作成と発行

それぞれについて、具体的な作業の内容を解説したいと思います。

解説することで「あーこれなら私にもお手伝いできそうだ」と広く思っていただけることを目的としています。ですので、当文書に対するツッコミは大歓迎です。

セキュリティ情報の発見・収集

なにはともあれ、セキュリティ情報がなくては作業が始まりません。
セキュリティ情報を発見したら、それが Vine Linux に該当するものかどうかの判断を行います。

セキュリティ情報の発見・収集

能動的に集める

web 巡回が基本になります。

日本語のリソース

• セキュリティーホールメモ ( http://www.st.ryukoku.ac.jp/~kjm/security/memo/)
• Japan Vulnerability Notes ( http://jvn.jp/)

英語のリソース

• Common Vulnerabilities and Exposures ( http://cve.mitre.org/)
• VUPEN ( http://www.vupen.com/english/)
• SecurityFocus ( http://www.securityfocus.com/)
• Secunia ( http://secunia.com/)
• Distro Watch ( http://distrowatch.com/)
• The Linux Kernel Archives ( http://kernel.org)

など。
ほかにも沢山情報源はあると思います。ご紹介頂けると助かります。

受動的に集める

各 Distribution の security 告知 Mailing List に登録しておくと、security update が発行されると自動的に情報が入るので便利です。 ただし、情報の入手が遅れがちになります。

また、上記の web 巡回先が RSS に対応していれば、RSS feed で情報を得ることもできます。

Vine Linux に該当するか

セキュリティ情報を発見しても、それが Vine Linux に該当するものかどうか判断しなければなりません。

• 脆弱性があるソフトウェアが Vine Linux に採用されているか？
• 脆弱性があるバージョンが Vine Linux に採用されているか？
• 脆弱性がある機能が有効になっているか？

の３つが大きな判断ポイントです。

次に、Vine Linux に該当する場合、

• Core, Main のカテゴリに属する package か？

を判断することになります。
もし、plus package になっていて security team の担当外と分かった場合、VinePlus Mailing List にその旨を投稿し packager さんに対応を促すことになります。

非該当の場合、Plus Package の場合

基本的には security watch team で管理する必要はありませんが、情報共有の意味で後述する Security BTS に登録しておきます。 これは、

• 複数のメンバーが同一の問題を調査するムダを防ぐ
• 調査済みの案件を再度調査してしまうのを防ぐ

ということを目的としています。

セキュリティ情報を Security BTS に登録

残念ながら、発見された脆弱性が Vine Linux に該当することが分かった場合、Security BTS に登録して管理することになります。

以下のような情報を揃えて、BTS に登録します。

• 脆弱性情報が載っている url
• CVE 番号
• 他の distribution の対応 url (security announce/bts へのリンク)
• 修正 patch / 修正 patch へのリンク
• 脆弱性の解説 / アナウンス文の案
• poc / poc へのリンク

これらが全部揃っている必要はありません。
あとから判明したものは、追加で登録すれば OK です。

対策済みパッケージの作成

package の作成は、通常の package 作成作業となんら変わるところはありません。

• 既存 package の src package を入手
• 対策 patch を追加、changelog 変更
• build する

という流れです。 ただし、既に release 済みの package を修正する作業ですので、

• 含まれるファイルが既存 package と変化ないこと
• 依存関係が既存 package と変化ないこと

が重要になります。
(もちろん、対策 patch 追加による依存関係の変化がある場合もありますが、その場合は plus カテゴリに依存していないことが重要になります)

対策済みの package が完成したら、security incoming に put し、security watch team のメンバーにテストしていただくことになります。 また、BTS に put した旨書き込んで、テスト中であることを宣言します。

対策済みバージョンがリリースされている場合

脆弱性が解消されたバージョンがリリースされていて、ABI などに変化がない場合は、新バージョンへの更新も検討します。
どちらかというと対策済みバージョンに更新したほうが、次の更新が有利になる(patch がそのまま流用できるなど)場合が多いので、対策済みバージョンへの更新を勧めます。

各arch への対応

現在（2011/03/09）Vine Linux では i386, ppc, x86_64 の３つのアーキテクチャをサポートしています。同時に３つのアーキテクチャのパッケージが作成できるのが理想（例えば ppc で build 出来ない、などの問題が早めに分かる）ですが、それは必須条件ではありません。
i386 package と src package を作成し、他のアーキテクチャは他のメンバーに build してもらうということも可能です。

これは通常の VineSeed の開発スタイルと同じです。

対策済みパッケージのテスト

対策済みパッケージの入手

対策済み package が put されたら、数時間後には security の apt-line に入ります。
テストする人は apt に security apt-line を登録しておけば、通常の apt の操作 (apt-get update, upgrade) で対策済みパッケージを入手できます。

この時に 単純な upgrade だけでは入手できず dist-upgrade が必要になった場合は要注意です。前節で述べた「依存関係に変化がないこと」が満たされていない恐れがあります。 BTS にその旨報告しましょう。

対策済みパッケージのテスト

次はその package のテストに移ります。 テストと一言でいってもいろいろなレベルが考えられます。

• よーわからんけど、新しい package 入れても動いている
• 新しい package が提供する機能に変化はない
• 新しい package の脆弱性が含まれていた機能に変化はない
• 脆弱性が確かに無くなっていることを PoC 使って確認した
• 脆弱性が確かに無くなっていることを Source Code レベルで確認した

などなど…。
全てのパッケージについて、全てのメンバーが最後のレベルまで確認できるのが理想ですが、それは無理というもの。
「とりあえず入れてみたけど、問題はなさそうだよ」や、「新パッケージ使ってみてるけど特に問題なさそうだよ」というのも立派なテスト結果です。

テスト結果が得られたら、その結果を問題が有っても無くても BTS に書き込みます。 「問題なさそうだから BTS には書かなくていいや」というのはテストしていないのと同じです。

errata 作成と発行

対策済み package をテストして問題がなさそうならば、正式に errata 発行されます。

errata 発行の際に一番手間を食うのが「案内文の作成」です。 脆弱性の BTS への登録時に「案内文の案」を同時に登録しておいて、メンバーで練るという流れがとれると理想かと思います。

最後に

security watch team の作業の流れを書いてきましたが、これを全部１人でやれる必要はありません。そのための "team" なのですから。
「あーこれならお手伝いできそうだ」という項目があれば、お手を挙げていただけると助かります。