Debian セキュリティ FAQ

最近、以下のような質問をよく受けますので、その回答をまとめてみました。

セキュリティ勧告につけられた署名が正しく検証できません。
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 の対象はなんでしょう?
セキュリティチームの構成を教えてください
セキュリティアップデートはどれくらいの期間提供されますか?
どのようにしたらパッケージの完全性をチェックできますか?
セキュリティアップデート後に、あるパッケージが壊れた場合どうすればいいですか?

A: おそらく、あなたの側の問題です。 debian-security-announce メーリングリストにはフィルタがあって、セキュリティチームのメンバーの正式な署名のあるメッセージしか投稿できないようになっています。

おそらく、お使いのメールソフトがメッセージをわずかに変更し、署名が壊れてしまったものと考えられます。ソフトウェアが MIME エンコーディングやデコーディング、タブとスペースの変換などを行っていないかどうかご確認ください。

fetchmail (mimedecode オプションをつけている場合) や formail (procmail 3.14 以降のみ) や evolution などがこのような問題の起こるソフトとして知られています。

A: セキュリティチームが何らかの問題に関する連絡を受けると、一人あるいは複数のメンバーがその問題を調査し、Debian の安定版 (stable) に対する影響 (脆弱性をもたらすかどうか) を考えます。もし Debian が脆弱になる場合は、その問題に対する修正を行うべく作業します。パッケージメンテナからの連絡がまだセキュリティチームになければ、そのメンテナにも連絡します。最後に修正がテストされ、新しいパッケージが準備され、それらを安定版に含まれる全てのアーキテクチャについてコンパイルし、アップロードします。これらのすべてが完了したら、セキュリティ勧告を公開します。

質問: なぜ旧バージョンのパッケージを変更しているのですか?

A: 最も重要なガイドラインは、セキュリティ修正を行ったパッケージの作成では、可能な限り最小の変更に留めるということです。私たちのユーザと開発者は作成された時点のリリースの動作に依存しきっているので、どのような変更であっても誰かのシステムが動かなくなることが起こり得ます。これはライブラリの場合に特に重要で、小さな変更といえどもアプリケーションのプログラムインターフェース (API) と、バイナリインターフェース (ABI) を絶対に変更しないようにしなければいけません。

このため、新しい上流のバージョンに移行することはよい解決策にはなりません。代わりに、該当の変更をバックポートすべきなのです。一般的に言って、上流のメンテナの人たちは必要に応じて快く協力してくれますし、たとえそのような協力が得られなくとも Debian セキュリティチームが協力します。

時にはセキュリティ修正をバックポートするのが不可能な場合、例えば多量のソースコードの変更や書き直しが必要になることがあります。そのような場合には、上流の新しいバージョンに移行することが必要になるかもしれません。但し、この場合にはセキュリティチームに事前の調整を仰いでください。

質問: 修正版のパッケージが security.debian.org に出るかどうかの判断基準はなんですか?

A: 安定版 (stable) ディストリビューションのパッケージにセキュリティの破れがあれば、そのパッケージは security.debian.org に登場することになります。他の理由で置かれることはありません。ここで「セキュリティの破れ」の程度が大きな問題になります。通常、セキュリティチームはパッケージのメンテナとともに新しいパッケージを準備します。ただし (信頼できる) 誰かが問題を追跡し、必要なパッケージをすべてコンパイルしてセキュリティチームに送ってくれたのであれば、些細なセキュリティ修正であってもそれは security.debian.org に置かれることになります。以下を参照してください。

セキュリティアップデートの目的は、ただひとつだけです。セキュリティ上の脆弱性に対する修正を提供することです。それは、通常のポイントリリースの手順を迂回して、安定版 (stable) リリースにそれ以外の変更を加えるための手段では、ありません。

質問: ローカル (リモート)の意味は?

A: 勧告の中には、手段をローカル、リモートという古い体系では区別できない脆弱性を扱うものがあります。ある脆弱性はリモートからは突くことができない、つまり、ネットワークポートに対して待ち受けるデーモンには該当しません。脆弱性のあるサービスが継続的にネットワークに接続していなくても、ネットワークから配置できる特定のファイルにより突くことができる場合、ローカル (リモート)と書きます。

こういった脆弱性はローカル及びリモートの間にある脆弱性で、ネットワークから配置できるもの、例えばメールの添付ファイルやダウンロードページが対象になることはよくあります。

質問: パッケージのバージョン番号からすると、私は今もなお危険なバージョンを使っているはずです!

A: 新しいリリースにアップグレードする代わりに、セキュリティ上の修正を安定版 (stable) に収録されたバージョンに適用 (バックポート) します。これは、パッケージの変更をできるだけ小さく留め、セキュリティ上の修正が予期しない変化や不具合を招くのを防ぐ目的があります。パッケージの更新履歴 (changelog) を調べたり、正確なバージョン番号を Debian セキュリティ勧告 (Security Advisery) に示されたバージョン番号と比較すれば、安全なバージョンを使っているかどうかを確認できます。

質問: 勧告を受け取りましたがあるプロセッサアーキテクチャ用のビルドが抜けているようです。

A: セキュリティチームは基本的に Debian がサポートするあらゆるアーキテクチャについて、更新されたパッケージのビルドを添えて勧告を発表します。しかし、ほとんどのアーキテクチャについてのビルドが準備でき、その一方で一部がまだ抜けているとき、他より遅れるアーキテクチャもあります。そういった少数アーキテクチャは私たちのユーザベースで言えば極一部ということになります。問題の緊急性によっては、私たちは勧告を直ちに発表することがあります。抜けているビルドは利用可能になり次第インストールされますが、さらなる通知は行われません。もちろん、i386 や amd64 用のビルドが存在しない勧告を発表することはありません。

質問: 不安定版 (unstable) のセキュリティはどうなっているのでしょうか?

A: 端的に言うと、セキュリティ上のサポートはありません。不安定版 (unstable) は頻繁に変化するものなので、セキュリティチームは適切なサポートをするのに必要なリソースを持っていません。安全な (そして安定した) サーバを構築したい場合には、安定版 (stable) を使い続けるよう強くおすすめします。

質問: テスト版 (testing) のセキュリティはどうなっているのでしょうか?

A: 安全な (そして安定した) サーバを構築したい場合には、安定版 (stable) を使い続けるよう強くおすすめします。しかし、テスト版 (testing) にも、セキュリティサポートはあります。 Debian テスト版 (testing) セキュリティチームが、テスト版 (testing) に入ってしまったセキュリティ上の問題点を扱っています。このチームは、修正済みのパッケージが不安定版 (unstable) からの (検疫期間を短縮しての) 移行による通常の方法でテスト版 (testing) にきちんと入ることを確認し、もしそれでもあまりにも時間がかかるようであれば、標準的な http://security.debian.org インフラストラクチャを通じてセキュリティアップデートを利用できるようにします。 http://security.debian.org インフラストラクチャを使用するには、 /etc/apt/sources.list に次の行をきちんと含めてください。

deb http://security.debian.org <コード名>/updates main

その上で、通常どおり、 apt-get update && apt-get upgrade を実行してください。

注意すべきは、テスト版 (testing) セキュリティチームによる作業は、必ずしも、既知のセキュリティバグがテスト版 (testing) においてすべて修正されているという保証にはならない、ということです。更新済みのパッケージの中には、テスト版 (testing) への移行待ちの状態にあるものも含まれているかもしれません。テスト版 (testing) のセキュリティインフラストラクチャに関するさらに詳しい情報は、http://secure-testing-master.debian.net/ で得られます。

質問: contrib と non-free のセキュリティはどのように扱われていますか?

A: 単刀直入に言うと、扱われていません。contrib と non-free は Debian ディストリビューションの公式な一部ではありませんし、リリースもされていません。ですので、セキュリティチームによるサポートはありません。non-free パッケージには、ソースがなかったり、ライセンスによって改変版の配布が認められていないものがあります。それらの場合には、修正版を作ることは全く不可能です。もし問題が修正可能で、そのパッケージのメンテナや他の誰かが正しく更新したパッケージを用意すれば、セキュリティチームはたいていそれらを処理し、勧告をリリースします。

質問: 不安定版 (unstable) ではバージョン 1.2.3-1 で修正済みと勧告にありますが、不安定版にあるのは 1.2.5-1 です。どういうことですか?

A: 私たちは、不安定版 (unstable) で問題が修正された最初のバージョンを記載するようにしています。しかし、時には、勧告を出す前にメンテナがさらに新しいバージョンをアップロードしてしまうことがあります。不安定版に含まれているバージョンを、私たちの記載したバージョンと比較してください。同じバージョンか高いバージョンなら、お使いのパッケージにはこの脆弱性の影響を受けないはずです。

質問: なぜ 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 に送ることができます。両方とも、セキュリティチームのメンバーによって読まれます。

もしあなたがパッケージメンテナで、自分のパッケージに関する問題について私たちに連絡を取りたい場合は、 Request Tracker で報告してください。PGP により暗号化したいのであれば通常の電子メールを使った方がいいですが。

必要ならば、Debian Security Contact key (key ID 0x90F8EEC5) でメールを暗号化することもできます。チームメンバー個人の各 PGP/GPG 鍵については、 keyring.debian.org 鍵サーバを参照してください。

質問: セキュリティ上の問題を見つけたと思います。これからどうすればいいのでしょう?

A: セキュリティ上の問題に関して知見を得たなら、それがあなたのパッケージでも他の人のパッケージでも、まずセキュリティチームに連絡してください。もし Debian セキュリティチームが報告された問題が脆弱性であり、他のベンダにも同じ問題があると判断したならば、それらのベンダにはセキュリティチームから連絡します。もしその脆弱性が未公開のものであるなら、他のベンダと協調してセキュリティ勧告を公開するようにしますので、主要なディストリビューションでは発表は同期したものになります。

その脆弱性が既に公に知られるものになっている場合は、Debian のバグ追跡システムに報告し、security というタグを付けるようにしてください。

あなたがもし Debian 開発者なら、以下を参照してください。

質問: 自分のパッケージにセキュリティ上の問題を見つけた場合、どうすればいいのでしょう?

A: セキュリティ上の問題に関して知見を得たなら、それがあなたのパッケージでも他の人のパッケージでも、まずセキュリティチームに連絡してください。連絡は Request Tracker を使って報告してくれることが望ましいですが 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 のアーカイブはセキュリティチームが維持管理しており、置かれるパッケージは全て承認を得たものです。代わりに、パッチや適切なソースパッケージを Request Tracker 経由または team@security.debian.org 宛のメールでセキュリティチームに送ってください。修正は、セキュリティチームのレビュー後にそのまま、あるいは変更を加えられ、最終的にアップロードされます。

もし、セキュリティアップロードに慣れてない、またはパッケージが完全なものであるという 100% の確信がない場合には、上記のやり方で incoming ディレクトリにアップロードするのはやめてください。セキュリティチームの壊れたパッケージを扱う際の選択肢は限られていますし、特にパッケージがまともなバージョン番号付けをされていない場合はできることはあまりありません。パッケージは現状では拒否できませんし、拒否できるようにすると buildd が混乱します。このため、セキュリティチームの手間を増やさないよう協力と、上記のメールを使う方法をお願いします。

デベロッパーズリファレンスには、何をすべきかに関して、完全な記述があります。

質問: バグの修正を入手しました。私が代わりに 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://security-master.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) リリースマネージャに話を振られるかもしれませんが。