警告! この翻訳は古過ぎるため、原文を御覧ください。
Debian セキュリティ FAQ
- debian-security-announce を経由してDSAを受け取りました。どのようにして脆弱なパッケージをアップグレードすれば良いでしょう?
- セキュリティ勧告につけられた署名が正しく検証できません。
- Debian ではセキュリティはどのように扱われているのでしょう?
- なぜ旧バージョンのパッケージを変更しているのですか?
- 修正版のパッケージが security.debian.org に出るかどうかの判断基準はなんですか?
- パッケージのバージョン番号からすると、 私は今もなお危険なバージョンを使っているはずです!
- 勧告を受け取りましたがあるプロセッサアーキテクチャ用の ビルドが抜けているようです。
- 不安定版 (unstable) のセキュリティはどうなっているのでしょうか?
- テスト版 (testing) のセキュリティはどうなっているのでしょうか?
- contrib と non-free のセキュリティはどのように扱われていますか?
- 不安定版 (unstable) ではバージョン 1.2.3-1 で修正済みと勧告にありますが、不安定版にあるのは 1.2.5-1 です。どういうことですか?
- なぜ security.debian.org の公式ミラーは ひとつも存在しないのですか?
- DSA 100 と DSA 102 があるのを見付けましたが、 DSA 101 が見当たりません。どこにありますか?
- セキュリティチームと連絡をとるには?
- セキュリティ上の問題を見つけたと思います。 これからどうすればいいのでしょう?
- 自分のパッケージにセキュリティ上の問題を見つけた場合、 どうすればいいのでしょう?
- セキュリティ勧告の一つに記載された パッケージをダウンロードしようとしているのですが、`file not found' エラーになります。
- バグ修正ができましたので、直接 security.debian.org にアップロードしたいのですが?
- バグの修正を入手しました。私が代わりに proposed-updates にアップロードできますか?
- パッケージに問題がないことに 相当の自信があります。アップロードの手順を教えてください。
- セキュリティに関するお手伝いがしたいのですが。
- proposed-updates の対象はなんでしょう?
- セキュリティチームの構成を教えてください
- セキュリティアップデートはどれくらいの期間 提供されますか?
- どのようにしたらパッケージの完全性をチェックできますか?
- セキュリティアップデート後に、 あるパッケージが壊れた場合どうすればいいですか?
- CVE 識別子とは何?
- Debian は全ての CVE 識別子について DSA を出していますか?
- Debian は CVE 識別子を割り当てられますか?
-
ローカル (リモート)
の意味は?
質問: debian-security-announce を経由してDSAを受け取りました。どのようにして脆弱なパッケージをアップグレードすれば良いでしょう?
A: DSAのメールで言うように、 発表された脆弱性により影響を受けるパッケージはアップグレードすべきです。 (apt-get update により利用可能パッケージ一覧を更新後に) apt-get upgrade によりシステムにある全パッケージをアップグレードするか apt-get install パッケージ により特定のパッケージだけをアップグレードすることができます。
告知のメールでは脆弱性が存在したソースパッケージに言及しています。 したがってソースパッケージから作られたバイナリパッケージを全て更新すべきです。 更新するバイナリパッケージは、 https://packages.debian.org/src:ソースパッケージ名 にアクセスし、更新するディストリビューションの「バイナリパッケージ:」行を確認します。 バイナリパッケージが多く非表示になっている場合は、 [...個のバイナリパッケージを表示]をクリックすると展開されます。
また、サービスや実行中のプロセスを再起動する必要があるかもしれません。 debian-goodies パッケージに収録されている checkrestart コマンドが再起動を要するものを見つけるのに役立つかもしれません。
質問: セキュリティ勧告につけられた署名が正しく検証できません。
A: おそらく、あなたの側の問題です。 debian-security-announce メーリングリストにはフィルタがあって、 セキュリティチームのメンバーの正式な署名のあるメッセージしか 投稿できないようになっています。
おそらく、お使いのメールソフトがメッセージをわずかに変更し、 署名が壊れてしまったものと考えられます。 ソフトウェアが MIME エンコーディングやデコーディング、 タブとスペースの変換などを行っていないかどうかご確認ください。
fetchmail (mimedecode オプションをつけている場合) や formail (procmail 3.14 以降のみ) や evolution などがこのような問題の起こるソフトとして知られています。
質問: Debian ではセキュリティはどのように扱われているのでしょう?
A: セキュリティチームが何らかの問題に関する連絡を受けると、 一人あるいは複数のメンバーがその問題を調査し、Debian の安定版 (stable) に対する影響 (脆弱性をもたらすかどうか) を考えます。もし Debian が脆弱になる場合は、その問題に対する修正を行うべく作業します。 パッケージメンテナからの連絡がまだセキュリティチームになければ、 そのメンテナにも連絡します。 最後に修正がテストされ、新しいパッケージが準備され、 それらを安定版に含まれる全てのアーキテクチャについてコンパイルし、 アップロードします。これらのすべてが完了したら、 セキュリティ勧告を公開します。
質問: なぜ旧バージョンのパッケージを変更しているのですか?
A: 最も重要なガイドラインは、セキュリティ修正を行ったパッケージの作成では、 可能な限り最小の変更に留めるということです。 私たちのユーザと開発者は作成された時点のリリースの動作に依存しきっているので、 どのような変更であっても誰かのシステムが動かなくなることが起こり得ます。 これはライブラリの場合に特に重要で、 小さな変更といえどもアプリケーションのプログラムインターフェース (API) と、 バイナリインターフェース (ABI) を絶対に変更しないようにしなければいけません。
このため、新しい上流のバージョンに移行することはよい解決策にはなりません。 代わりに、該当の変更をバックポートすべきなのです。 一般的に言って、上流のメンテナの人たちは必要に応じて快く協力してくれますし、 たとえそのような協力が得られなくとも Debian セキュリティチームが協力します。
時にはセキュリティ修正をバックポートするのが不可能な場合、 例えば多量のソースコードの変更や書き直しが必要になることがあります。 そのような場合には、上流の新しいバージョンに移行することが必要になるかもしれません。 但し、この場合にはセキュリティチームに事前の調整を仰いでください。
質問: 修正版のパッケージが security.debian.org に出るかどうかの判断基準はなんですか?
A: 安定版 (stable) ディストリビューションのパッケージに セキュリティの破れがあれば、そのパッケージは security.debian.org に登場することになります。他の理由で置かれることはありません。 ここで「セキュリティの破れ」の程度が大きな問題になります。 通常、セキュリティチームはパッケージのメンテナとともに新しい パッケージを準備します。ただし (信頼できる) 誰かが問題を追跡し、 必要なパッケージをすべてコンパイルして セキュリティチームに送ってくれたのであれば、 些細なセキュリティ修正であってもそれは security.debian.org に置かれることになります。以下を参照してください。
セキュリティアップデートの目的は、ただひとつだけです。 セキュリティ上の脆弱性に対する修正を提供することです。 それは、通常のポイントリリースの手順を迂回して、安定版 (stable) リリースにそれ以外の変更を加えるための手段では、ありません。
質問: パッケージのバージョン番号からすると、 私は今もなお危険なバージョンを使っているはずです!
A: 新しいリリースにアップグレードする代わりに、セキュリティ上の修正を安定版 (stable) に収録されたバージョンに適用 (バックポート) します。 これは、パッケージの変更をできるだけ小さく留め、 セキュリティ上の修正が予期しない変化や不具合を招くのを防ぐ目的があります。 パッケージの更新履歴 (changelog) を調べたり、正確なバージョン番号を Debian セキュリティ勧告 (Security Advisery) に示されたバージョン番号と比較すれば、 安全なバージョンを使っているかどうかを確認できます。
質問: 勧告を受け取りましたがあるプロセッサアーキテクチャ用の ビルドが抜けているようです。
A: セキュリティチームは基本的に Debian がサポートするあらゆるアーキテクチャについて、 更新されたパッケージのビルドを添えて勧告を発表します。しかし、 ほとんどのアーキテクチャについてのビルドが準備でき、 その一方で一部がまだ抜けているとき、他より遅れるアーキテクチャもあります。 そういった少数アーキテクチャは私たちのユーザベースで言えば極一部ということになります。 問題の緊急性によっては、私たちは勧告を直ちに発表することがあります。 抜けているビルドは利用可能になり次第インストールされますが、 さらなる通知は行われません。もちろん、i386 や amd64 用のビルドが存在しない勧告を発表することはありません。
質問: 不安定版 (unstable) のセキュリティはどうなっているのでしょうか?
A: 不安定版 (unstable) のセキュリティは主として、 セキュリティチームではなくパッケージのメンテナにより対処されます。 緊急性の高いものについては、 そのメンテナが活動していないことにセキュリティチームが気付いたときに セキュリティだけを修正してアップロードすることはあるかもしれませんが、 優先順位は常に安定版 (stable) にあります。 安全な (そして安定した) サーバを構築したい場合には、 安定版 (stable) を使い続けるよう強くおすすめします。
質問: テスト版 (testing) のセキュリティはどうなっているのでしょうか?
A: テスト版 (testing) のセキュリティは不安定版 (unstable) に対するプロジェクト全体のセキュリティへの取り組みの恩恵を受けます。 しかし、その移行には最低でも2日間の遅延があり、 移行のためにセキュリティの修正が保留される可能性もあります。 セキュリティチームは重要なセキュリティアップロードを控えることにより その移行の促進を支援しますが、これは常に可能とは限らず、 遅延が発生することもあります。特に新しい安定版 (stable) リリースの後で新しいバージョンが多数不安定版 (unstable) にアップロードされているようなときにはテスト版 (testing) のセキュリティ修正は大きく遅れるかもしれません。 安全な (そして安定した) サーバを構築したい場合には、 安定版 (stable) を使い続けるよう強くおすすめします。
質問: contrib と non-free のセキュリティはどのように扱われていますか?
A: 単刀直入に言うと、扱われていません。contrib と non-free は Debian ディストリビューションの公式な一部ではありませんし、 リリースもされていません。ですので、セキュリティチームによる サポートはありません。non-free パッケージには、ソースがなかったり、 ライセンスによって改変版の配布が認められていないものがあります。 それらの場合には、修正版を作ることは全く不可能です。もし問題が修正可能で、 そのパッケージのメンテナや他の誰かが正しく更新したパッケージを用意すれば、 セキュリティチームはたいていそれらを処理し、勧告をリリースします。
質問: 不安定版 (unstable) ではバージョン 1.2.3-1 で修正済みと勧告にありますが、不安定版にあるのは 1.2.5-1 です。どういうことですか?
A: 私たちは、不安定版 (unstable) で問題が修正された最初のバージョンを記載するようにしています。しかし、時には、 勧告を出す前にメンテナがさらに新しいバージョンをアップロードしてしまうことがあります。 不安定版に含まれているバージョンを、私たちの記載したバージョンと比較してください。 同じバージョンか高いバージョンなら、 お使いのパッケージにはこの脆弱性の影響を受けないはずです。 確実を期したい場合は apt-get changelog パッケージ名 によりそのパッケージの変更履歴を確認し、 その修正を告知している項目を探すと良いでしょう。
質問: なぜ security.debian.org の公式ミラーは ひとつも存在しないのですか?
A: 実質的には存在します。複数の公式ミラーが、DNS エイリアスによって導入されています。security.debian.org は、できるだけ早くかつ容易にセキュリティアップデートを提供するのが目的です。
非公式のミラーの使用を推奨すると、必要以上に複雑さが増してしまいます。 それによって、ミラーが最新に保たれていない場合にフラストレーションの元になる可能性もあります。
質問: DSA 100 と DSA 102 があるのを見付けましたが、 DSA 101 が見当たりません。どこにありますか?
A: いくつかの案件については、数団体のベンダ (ほとんどが GNU/Linux のベンダですが、BSD のベンダも含まれています) がセキュリティ勧告を整合させ、これらのベンダが同時に セキュリティ勧告を出せるようにしています。 これによって、より長い時間を必要とするベンダ (例えば、長い品質管理プロセスをパッケージがパスしないといけない場合や、 複数のアーキテクチャやバイナリをサポートしていたりする場合) が不利にならないようにしています。 私たちのセキュリティチームもまた、前もってセキュリティ勧告を 準備しておきます。時々、準備して置いてあるセキュリティ勧告が 発表できるようになる前に、他のセキュリティ勧告を出さないと いけなくなることがあります。このとき、セキュリティ勧告の 番号をひとつ (または複数) とばして発表します。
A: セキュリティ情報は security@debian.org または team@security.debian.org に送ることができます。 両方とも、セキュリティチームのメンバーによって読まれます。
必要ならば、Debian Security Contact key (key ID 0x0D59D2B15144766A14D241C66BAF400B05C3E651) でメールを暗号化することもできます。 チームメンバー個人の各 PGP/GPG 鍵については、 keyring.debian.org 鍵サーバを 参照してください。
質問: セキュリティ上の問題を見つけたと思います。 これからどうすればいいのでしょう?
A: セキュリティ上の問題に関して知見を得たなら、 それがあなたのパッケージでも他の人のパッケージでも、 まずセキュリティチームに連絡してください。もし Debian セキュリティチームが報告された問題が脆弱性であり、 他のベンダにも同じ問題があると判断したならば、 それらのベンダにはセキュリティチームから連絡します。 もしその脆弱性が未公開のものであるなら、 他のベンダと協調してセキュリティ勧告を公開するようにしますので、 主要なディストリビューションでは発表は同期したものになります。
その脆弱性が既に公に知られるものになっている場合は、Debian
のバグ追跡システムに報告し、security
というタグを付けるようにしてください。
あなたがもし Debian 開発者なら、以下を参照してください。
質問: 自分のパッケージにセキュリティ上の問題を見つけた場合、 どうすればいいのでしょう?
A: セキュリティ上の問題に関して知見を得たなら、 それがあなたのパッケージでも他の人のパッケージでも、team@security.debian.org 宛の電子メールでまずセキュリティチームに連絡してください。 セキュリティチームは、未解決のセキュリティ問題の履歴を採り、 セキュリティ問題に関してメンテナに協力ないし修正を行い、 セキュリティ勧告の公開に関して責任を持ち、security.debian.org を維持管理しています。
デベロッパーズリファレンスには、何をすべきかに関して、 完全な記述があります。
セキュリティチームの事前の合意なしに、不安定版 (unstable) 以外にアップロードすることは、避けてください。混乱が生じ、 余分な仕事が必要になってしまいます。
質問: セキュリティ勧告の一つに記載された パッケージをダウンロードしようとしているのですが、`file not found' エラーになります。
A: 新しいバグ修正が security.debian.org の古いパッケージを上書き更新することになる場合、 新パッケージがインストールされた時点で古いものは 速やかに削除される可能性が高いからです。このため、この場合には `file not found' エラーになります。 私たちはセキュリティバグのあることが分かっているパッケージを、 本当に必要な期間以上には配布したくはありませんので。
最新のセキュリティ勧告記載のパッケージを用いてください。
最新の勧告は、debian-security-announce で公表されます。そして
パッケージのアップグレードの前に単に apt-get update
とするのが最良のやり方です。
質問: バグ修正ができましたので、直接 security.debian.org にアップロードしたいのですが?
A: それはできません。security.debian.org のアーカイブはセキュリティチームが維持管理しており、 置かれるパッケージは全て承認を得たものです。 代わりに、パッチや適切なソースパッケージを team@security.debian.org 宛のメールでセキュリティチームに送ってください。 修正は、セキュリティチームのレビュー後にそのまま、 あるいは変更を加えられ、最終的にアップロードされます。
デベロッパーズリファレンスには、何をすべきかに関して、 完全な記述があります。
質問: バグの修正を入手しました。私が代わりに proposed-updates にアップロードできますか?
A: 技術的には可能です。しかし、すべきではありません。
というのは、セキュリティチームの仕事と、深刻な干渉を起こすからです。
security.debian.org のパッケージは、自動的に proposed-updates
ディレクトリにコピーされます。もし、すでにアーカイブに
同じバージョンまたは高いバージョンのパッケージがある場合には、
セキュリティアップデートはアーカイブシステムによって拒否されてしまいます。
そうすると、安定版 (stable) ディストリビューションは結局、
proposed-updates ディレクトリの間違った
パッケージが拒否されない限り、
そのパッケージのセキュリティアップデートがない状態になってしまいます。
その代わり、セキュリティチームに連絡してください。その際、
脆弱性に関する詳細を書き、ソースファイル (つまり、diff.gz と dsc
ファイル) をメールに添付してください。
デベロッパーズリファレンスには、何をすべきかに関して、 完全な記述があります。
質問: パッケージに問題がないことに 相当の自信があります。アップロードの手順を教えてください。
A: あなたのパッケージが問題を起こさない、すなわちバージョン番号付けは妥当で
(つまり、安定版 (stable) のバージョンより大きく、
テスト版/不安定版のバージョンより小さい)、
セキュリティ修正に関わらずパッケージの挙動に変更はなく、
正しいディストリビューション (oldstable-security か
stable-security) 向けにコンパイルされたものであり、
security.debian.org
に初めてアップロードされるものについては元のソースを含んでいて、
最新版に当てたパッチはきれいに当たっていて、
該当するセキュリティ修正のみを変更するものであり
(interdiff -z と .diff.gz
ファイルの両方のチェックを行ってください)、
少なくとも 3 回パッチの妥当性を確認済みで、debdiff
が何も変更箇所を指摘しないならば、security.debian.org の incoming
ディレクトリ ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue
にファイルをアップロードしても構いません。その際、全詳細とリンクを同時に
team@security.debian.org に連絡してください。
A: 問題を security@debian.org に報告する前に、まず調査をしてください。 パッチを提供していただければ、処理が迅速になります。 bugtraq のメールを単に転送することは避けてください。 我々も同じメールを受信していますから。 単に転送するのではなく、bugtraq で報告された事項に対する 追加情報の場合は、是非報告してください。
セキュリティの作業を始める良い方法は、Debian Security Tracker (説明) を手伝うことです。
質問: proposed-updates の対象はなんでしょう?
A: このディレクトリには、Debian 安定版 (stable) の次のリビジョンに入るであろうパッケージが含まれています。 メンテナから安定版向けのパッケージがアップロードされると、 それらは proposed-updates ディレクトリに置かれます。 安定版は安定であることを意図されていますから、 自動的な更新は行われません。 セキュリティチームは安定版への勧告を行った際、 その修正パッケージをアップロードしますが、それらはまず proposed-updates に置かれます。2〜3 ヶ月おきに安定版のリリース管理者は proposed-updates にあるパッケージを一通り調べ、 それらが安定版にふさわしいかどうかを議論します。 そしてこれらは安定版の新しいリビジョン (例えば 2.2r3 とか 2.2r4 とか) に組み込まれます。ふさわしくないパッケージは拒否され、 proposed-updates からもなくなります。
(セキュリティチームではなく) メンテナによって proposed-updates/ ディレクトリにアップロードされたパッケージは、セキュリティチームによって サポートされませんのでご注意ください。
A: Debian セキュリティチームは、数人の役員と書記から構成されています。 チームへの参加者は、チーム自身が任命します。
質問: セキュリティアップデートはどれくらいの期間 提供されますか?
A: セキュリティチームは、次の安定版がリリースされてから1年後まで、 安定版をサポートしようと努めます。ただし、次の次の安定版が1年以内に リリースされた場合はその限りではありません。というのは、 同時に2つのディストリビューションをサポートすることでさえかなり難しいので、 3つのディストリビューションをサポートすることは不可能だからです。
質問: どのようにしたらパッケージの完全性をチェックできますか?
A: Release ファイルのサインを、アーカイブに使った公開鍵で照合することでチェックすることができます。Release ファイルは Packages ファイルと Sources ファイルのチェックサムを含んでおり、Packages ファイルと Sources ファイルはバイナリパッケージとソースパッケージのチェックサムを含んでいます。 パッケージの完全性をチェックする方法については、Debian セキュリティマニュアルに説明があります。
質問: セキュリティアップデート後に、 あるパッケージが壊れた場合どうすればいいですか?
A: まず初めに、なぜそのパッケージが壊れたのか、また、 それがどのようにセキュリティアップデートと関連するのかを解明してください。 その後、それが深刻な問題ならセキュリティチームに、 それほど深刻でなければ安定版 (stable) リリースマネージャに連絡してください。 何が悪いのか解明はできなくても解決方法が分かる場合も、 セキュリティチームに話してください。安定版 (stable) リリースマネージャに話を振られるかもしれませんが。
A: The Common Vulnerabilities and Exposures プロジェクトは特定のセキュリティ脆弱性に対して CVE 識別子と呼ばれる一意の名前を割り当て、 特定の問題について一意に参照することが容易になります。さらなる情報が Wikipedia にあります。
質問: Debian は全ての CVE 識別子について DSA を出していますか?
A: Debian セキュリティチームは発表された CVE 識別子を全て追跡し、関連する Debian パッケージを調べて Debian での影響を判断します。CVE 識別子に何かが割り当てられたこと自体は、その問題が Debian システムに重大な脅威を与えるということには必ずしもなりません。この情報は Debian Security Tracker で追跡され、それが重大だと判断した問題については Debian セキュリティ勧告が出されます。
DSA の基準に合わないような影響の低い問題については次期 Debian リリース、現在の安定版 (stable) や旧安定版 (oldstable) ディストリビューションのポイントリリース、 あるいはもっと重大な脆弱性についての DSA により修正されることがあります。
質問: Debian は CVE 識別子を割り当てられますか?
A: Debian には CVE 番号を割り当てる権限があり、 識別子を割り当てることはできますが、CVE ポリシーにより未公開の問題に限られます。Debian のソフトウェアについて未公開のセキュリティ脆弱性を知っていて識別子を得たい場合は Debian セキュリティチームに連絡を取ってください。 その脆弱性が既に公開されている場合は CVE OpenSource リクエスト HOWTO の手順に従うことを勧めます。
Deprecated Debian security FAQ
The field Problem type in DSA mails is not used since April 2014.
A: 勧告の中には、手段をローカル、
リモートという古い体系では区別できない脆弱性を扱うものがあります。
ある脆弱性はリモートからは突くことができない、つまり、
ネットワークポートに対して待ち受けるデーモンには該当しません。
脆弱性のあるサービスが継続的にネットワークに接続していなくても、
ネットワークから配置できる特定のファイルにより突くことができる場合、
ローカル (リモート)
と書きます。
こういった脆弱性はローカル及びリモートの間にある脆弱性で、 ネットワークから配置できるもの、 例えばメールの添付ファイルやダウンロードページが対象になることはよくあります。