wiki:security/workflow

Version 10 (modified by iwamoto, 9 years ago) (diff)

--

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

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

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

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

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

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

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

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

能動的に集める

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

日本語のリソース

英語のリソース

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

受動的に集める

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

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

Vine Linux に該当するか

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

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

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

次に、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 の3つのアーキテクチャをサポートしています。同時に3つのアーキテクチャのパッケージが作成できるのが理想(例えば 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 の作業の流れを書いてきましたが、これを全部1人でやれる必要はありません。そのための "team" なのですから。
「あーこれならお手伝いできそうだ」という項目があれば、お手を挙げていただけると助かります。