wiki:security/workflow

Version 5 (modified by iwamoto, 13 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 さんに対応を促すことになります。

セキュリティ情報を 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 がそのまま流用できるなど)場合が多いので、対策済みバージョンへの更新を勧めます。

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

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

対策済み 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 BTS

情報を整理し、進捗を明確にするために BTS が用意されています。
アクセスは security watch team に限定されていますので、PoC などの取り扱いに考慮するべき情報も登録できます。

また、BTS に書き込みを行うと、後述する security ML に投稿内容が自動的に流れ、メンバーに周知されるようになっています。

security ML

security watch team 専用のメーリングリストです。
BTS と同じく security watch team 限定ですので、PoC などの取り扱いに考慮するべき情報も流すことができます。

security apt-line

作成した対策済み package をメンバー宛に公開するための apt-line です。

security incoming に対策済み package を put すると、数時間後には通常の apt の操作で、対策済みパッケージをインストールできます。

これも BTS, ML と同じく security watch team 限定公開です。

作業のために用意するべき環境

以下の環境が必要です。

  • security watch の担当するバージョンの Vine Linux が入ったマシン

ごく普通の環境ですね。
但し、少し条件があります。

  • VineSeed の package、他の distribution の package、local で make したもの などが入っていないこと

これは package の build、テストの際に想定外の影響がでるのを未然に防止するためです。

仮想マシン上でのテスト

通常の package のテストにおいては、仮想マシン上に install された Vine Linux でも全く問題ありません。ばんばん!テスト環境として利用しましょう。

但し(ある意味当然ですが)ハードウェアに密着した package (linux kernel、driver module など)のテストは限定的にしか行えないことに注意する必要があります。

最後に

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