Changes between Initial Version and Version 1 of security/workflow

Timestamp:

2011/03/08 00:02:00 (13 years ago)

Author:

iwamoto

Comment:

--

security/workflow

@@ +1 @@
+
+= セキュリティーウォッチチームの作業 =
+
+セキュリティーウォッチチームでは、以下のような作業を行っています。
+
+ * セキュリティ情報を発見・収集
+ * セキュリティ情報を Security BTS に登録
+ * 対策済みパッケージの作成
+ * 対策済みパッケージのテスト
+ * errata 作成と発行
+
+それぞれについて、具体的な作業の内容を解説したいと思います。
+
+解説することで「あーこれなら私にもお手伝いできそうだ」と広く思っていただけることを目的としています。ですので、当文書に対するツッコミは大歓迎です。
+
+== セキュリティ情報の発見・収集 ==
+
+なにはともあれ、セキュリティ情報がなくては作業が始まりません。[[BR]]
+セキュリティ情報を発見したら、それが 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/)
+ * 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 か？
+
+を判断することになります。[[BR]]
+もし、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 へのリンク
+
+これらが全部揃っている必要はありません。[[BR]]
+あとから判明したものは、追加で登録すれば OK です。
+
+== 対策済みパッケージの作成 ==
+
+package の作成は、通常の package 作成作業となんら変わるところはありません。
+
+ * 既存 package の src package を入手
+ * 対策 patch を追加、changelog 変更
+ * build する
+
+という流れです。
+ただし、既に release 済みの package を修正する作業ですので、
+
+ * 含まれるファイルが既存 package と変化ないこと
+ * 依存関係が既存 package と変化ないこと
+
+が重要になります。[[BR]]
+(もちろん、対策 patch 追加による依存関係の変化がある場合もありますが、その場合は plus カテゴリに依存していないことが重要になります)
+
+対策済みの package が完成したら、security incoming に put し、security watch team のメンバーにテストしていただくことになります。
+また、BTS に put した旨書き込んで、テスト中であることを宣言します。
+
+=== 対策済みバージョンがリリースされている場合 ===
+
+脆弱性が解消されたバージョンがリリースされていて、ABI などに変化がない場合は、新バージョンへの更新も検討します。[[BR]]
+どちらかというと対策済みバージョンに更新したほうが、次の更新が有利になる(patch がそのまま流用できるなど)場合が多いので、対策済みバージョンへの更新を勧めます。
+
+== 対策済みパッケージのテスト ==
+
+=== 対策済みパッケージの入手 ===
+
+対策済み package が put されたら、数時間後には security の apt-line に入ります。[[BR]]
+テストする人は apt に security apt-line を登録しておけば、通常の apt の操作 (apt-get update, upgrade) で対策済みパッケージを入手できます。
+
+この時に 単純な upgrade だけでは入手できず dist-upgrade が必要になった場合は要注意です。前節で述べた「依存関係に変化がないこと」が満たされていない恐れがあります。
+BTS にその旨報告しましょう。
+
+=== 対策済みパッケージのテスト ===
+
+次はその package のテストに移ります。
+テストと一言でいってもいろいろなレベルが考えられます。
+
+ * よーわからんけど、新しい package 入れても動いている
+ * 新しい package が提供する機能に変化はない
+ * 新しい package の脆弱性が含まれていた機能に変化はない
+ * 脆弱性が確かに無くなっていることを PoC 使って確認した
+ * 脆弱性が確かに無くなっていることを Source Code レベルで確認した
+
+などなど…。[[BR]]
+全てのパッケージについて、全てのメンバーが最後のレベルまで確認できるのが理想ですが、それは無理というもの。
+「とりあえず入れてみたけど、問題はなさそうだよ」や、「新パッケージ使ってみてるけど特に問題なさそうだよ」というのも立派なテスト結果です。
+
+テスト結果が得られたら、その結果を BTS に書き込みます。
+
+== errata 作成と発行 ==
+
+対策済み package をテストして問題がなさそうならば、正式に errata 発行されます。[[BR]]
+
+errata 発行の際に一番手間を食うのが「案内文の作成」です。
+脆弱性の BTS への登録時に「案内文の案」を同時に登録しておいて、メンバーで練るというながれがとれると理想かと思います。
+
+== 最後に ==
+
+security watch team の作業の流れを書いてきましたが、これを全部１人でやれる必要はありません。そのための "team" なのですから。[[BR]]
+「あーこれならお手伝いできそうだ」という項目があれば、お手を挙げていただけると助かります。