[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
security/faq (1.54)
http://www.debian.org/security/faq
rev 1.54
purged ja 1.47:
http://cvs.debian.org/*checkout*/webwml/japanese/security/Attic/faq.wml?content-type=text%2Fplain&rev=1.28&root=webwml
en 1.47 -> 1.54:
http://cvs.debian.org/webwml/english/security/faq.wml?root=webwml&r1=text&tr1=1.47&r2=text&tr2=1.54&diff_format=u
--
victory
http://debian.rsz.jp/
don't include my addresses in mail body...
----------------------------------------------------------------
#use wml::debian::template title="Debian セキュリティ FAQ"
#include "$(ENGLISHDIR)/security/faq.inc"
#use wml::debian::translation-check translation="1.54"
<p>最近、以下のような質問をよく受けますので、その回答をまとめてみました。</p>
<maketoc>
<toc-add-entry name=signature>セキュリティ勧告につけられた署名が正しく検証できません。</toc-add-entry>
<p>A: おそらく、あなたの側の問題です。
<a href="http://lists.debian.org/debian-security-announce/";>debian-security-announce</a>
メーリングリストにはフィルタがあって、
セキュリティチームのメンバーの正式な署名のあるメッセージしか
投稿できないようになっています。</p>
<p>おそらく、お使いのメールソフトがメッセージをわずかに変更し、
署名が壊れてしまったものと考えられます。
ソフトウェアが MIME エンコーディングやデコーディング、
タブとスペースの変換などを行っていないかどうかご確認ください。</p>
<p>fetchmail (mimedecode オプションをつけている場合) や formail
(procmail 3.14 以降のみ) や evolution
などがこのような問題の起こるソフトとして知られています。</p>
<toc-add-entry name="handling">Debian
ではセキュリティはどのように扱われているのでしょう?</toc-add-entry>
<p>A: セキュリティチームが何らかの問題に関する連絡を受けると、
一人あるいは複数のメンバーがその問題を調査し、Debian の安定版
(stable) に対する影響 (脆弱性をもたらすかどうか) を考えます。もし
Debian が脆弱になる場合は、その問題に対する修正を行うべく作業します。
パッケージメンテナからの連絡がまだセキュリティチームになければ、
そのメンテナにも連絡します。
最後に修正がテストされ、新しいパッケージが準備され、
それらを安定版に含まれる全てのアーキテクチャについてコンパイルし、
アップロードします。これらのすべてが完了したら、
セキュリティ勧告を公開します。</p>
<toc-add-entry name=oldversion>なぜ旧バージョンのパッケージを変更しているのですか? </toc-add-entry>
<p>最も重要なガイドラインは、セキュリティ修正を行ったパッケージの作成では、
可能な限り最小の変更に留めるということです。
私たちのユーザと開発者は作成された時点のリリースの動作に依存しきっているので、
どのような変更であっても誰かのシステムが動かなくなることが起こり得ます。
これはライブラリの場合に特に重要で、
小さな変更といえどもアプリケーションのプログラムインターフェース (API) と、
バイナリインターフェース (ABI) を絶対に変更しないようにしなければいけません。
</p>
<p>このため、新しい上流のバージョンに移行することはよい解決策にはなりません。
代わりに、該当の変更をバックポートすべきなのです。
一般的に言って、上流のメンテナの人たちは必要に応じて快く協力してくれますし、
たとえそのような協力が得られなくとも Debian セキュリティチームが協力します。
</p>
<p>時にはセキュリティ修正をバックポートするのが不可能な場合、
例えば多量のソースコードの変更や書き直しが必要になることがあります。
そのような場合には、上流の新しいバージョンに移行することが必要になるかもしれません。
但し、この場合にはセキュリティチームに事前の調整を仰いでください。</p>
<toc-add-entry name=policy>修正版のパッケージが security.debian.org
に出るかどうかの判断基準はなんですか?</toc-add-entry>
<p>A: 安定版 (stable) ディストリビューションのパッケージに
セキュリティの破れがあれば、そのパッケージは security.debian.org
に登場することになります。他の理由で置かれることはありません。
ここで「セキュリティの破れ」の程度が大きな問題になります。
通常、セキュリティチームはパッケージのメンテナとともに新しい
パッケージを準備します。ただし (信頼できる) 誰かが問題を追跡し、
必要なパッケージをすべてコンパイルして
セキュリティチームに送ってくれたのであれば、
些細なセキュリティ修正であってもそれは security.debian.org
に置かれることになります。以下を参照してください。</p>
<p>セキュリティアップデートの目的は、ただひとつだけです。
セキュリティ上の脆弱性に対する修正を提供することです。
それは、通常のポイントリリースの手順を迂回して、安定版 (stable)
リリースにそれ以外の変更を加えるための手段では、ありません。</p>
<toc-add-entry name=localremote>「ローカル (リモート)」の意味は?</toc-add-entry>
<p>A:勧告の中には、手段をローカル、
リモートという古い体系では区別できない脆弱性を扱うものがあります。
ある脆弱性はリモートからは突くことができない、つまり、
ネットワークポートに対して待ち受けるデーモンには該当しません。
脆弱性のあるサービスが継続的にネットワークに接続していなくても、
ネットワークから配置できる特定のファイルにより突くことができる場合、
「ローカル (リモート)」と書きます。</p>
<p>こういった脆弱性はローカル及びリモートの間にある脆弱性で、
ネットワークから配置できるもの、
例えばメールの添付ファイルやダウンロードページが対象になることはよくあります。</p>
<toc-add-entry name=version>パッケージのバージョン番号からすると、
私は今もなお危険なバージョンを使っているはずです!</toc-add-entry>
<p>A: 新しいリリースにアップグレードする代わりに、セキュリティ上の修正を安定版
(stable) に収録されたバージョンに適用 (バックポート) します。
これは、パッケージの変更をできるだけ小さく留め、
セキュリティ上の修正が予期しない変化や不具合を招くのを防ぐ目的があります。
パッケージの更新履歴 (changelog) を調べたり、正確なバージョン番号を
Debian セキュリティ勧告 (Security Advisery)
に示されたバージョン番号と比較すれば、
安全なバージョンを使っているかどうかを確認できます。</p>
<toc-add-entry name=testing>テスト版 (<tt>testing</tt>) と不安定版
(<tt>unstable</tt>) のセキュリティはどうなっているのでしょうか?</toc-add-entry>
<p>A: 端的に言うと、これらにはセキュリティ上のサポートはありません。
テスト版 (testing) と不安定版 (unstable) は頻繁に変化するものなので、
セキュリティチームは適切なサポートをするのに必要なリソースを持っていません。
安全な (そして安定した) サーバを構築したい場合には、
安定版 (stable) を使い続けるよう強くおすすめします。
但し、<a href="http://secure-testing-master.debian.net/";>テスト版
(testing) セキュリティチーム</a>が組織され、
この現状を変えようという動きが進行しています。
このチームは、セキュリティサポートをテスト版 (testing)
に対しても提供し、さらには不安定版 (unstable)
にも広げようとするチームです。</p>
<toc-add-entry name=testing-security>テスト版 (<tt>testing</tt>)
のセキュリティアップデートはどのようにして行われますか?</toc-add-entry>
<p>A: セキュリティアップデートは、不安定版 (<tt>unstable</tt>)
を経由してテスト版 (<tt>testing</tt>) に移行されます。通常は優先度を high
にしてアップロードされるので、パッケージの検査期間は二日間に短縮されます。
この期間を過ぎると、すべてのアーキテクチャ向けにビルドされ、
テスト版での依存関係が満たされると、パッケージは自動的にテスト版へと移行されます。</p>
<p>通常の移行プロセスに時間がかかるようであれば、<a
href="http://secure-testing-master.debian.net/";>テスト版 (testing)
セキュリティチーム</a>も、セキュリティ修正を作成してテスト版
(testing) セキュリティのリポジトリに用意します。</p>
<toc-add-entry name=contrib><tt>contrib</tt> と <tt>non-free</tt>
のセキュリティはどのように扱われていますか?</toc-add-entry>
<p>A: 単刀直入に言うと、扱われていません。contrib と non-free
は Debian ディストリビューションの公式な一部ではありませんし、
リリースもされていません。ですので、セキュリティチームによる
サポートはありません。non-free パッケージには、ソースがなかったり、
ライセンスによって改変版の配布が認められていないものがあります。
それらの場合には、修正版を作ることは全く不可能です。もし問題が修正可能で、
そのパッケージのメンテナや他の誰かが正しく更新したパッケージを用意すれば、
セキュリティチームはたいていそれらを処理し、勧告をリリースします。</p>
<toc-add-entry name=mirror>なぜ security.debian.org の公式ミラーは
ひとつも存在しないのですか?</toc-add-entry>
<p>A: security.debian.org は、できるだけ早くかつ容易に
セキュリティアップデートを提供するのが目的です。</p>
<p>非公式のミラーの使用を推奨すると、不必要な複雑さが導入され、
ミラーが最新でないと問題が起きる可能性もあります。
しかし、将来、公式なミラーを用意する計画があります。</p>
<toc-add-entry name=missing>DSA 100 と DSA 102 があるのを見付けましたが、
DSA 101 が見当たりません。どこにありますか?</toc-add-entry>
<p>A: いくつかの案件については、数団体のベンダ (ほとんどが GNU/Linux
のベンダですが、BSD のベンダも含まれています)
がセキュリティ勧告を整合させ、これらのベンダが同時に
セキュリティ勧告を出せるようにしています。
これによって、より長い時間を必要とするベンダ
(例えば、長い品質管理プロセスをパッケージがパスしないといけない場合や、
複数のアーキテクチャやバイナリをサポートしていたりする場合)
が不利にならないようにしています。
私たちのセキュリティチームもまた、前もってセキュリティ勧告を
準備しておきます。時々、準備して置いてあるセキュリティ勧告が
発表できるようになる前に、他のセキュリティ勧告を出さないと
いけなくなることがあります。このとき、セキュリティ勧告の
番号をひとつ (または複数) とばして発表します。</p>
<toc-add-entry name=contact>セキュリティチームと連絡をとるには?</toc-add-entry>
<p>A: セキュリティ情報は security@debian.org
または team@security.debian.org に送ることができます。
両方とも、セキュリティチームのメンバーによって読まれます。</p>
<p>機密を要する情報がある場合には、セキュリティチームだけが読んでいる
team@security.debian.org にご連絡ください。</p>
<p>必要ならば、Debian Security Contact key (key ID <a
href="http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&exact=on&search=0x363CCD95";>\
0x363CCD95</a>) でメールを暗号化することもできます。
<a href="keys.txt">PGP/GPG keys for the security team</a> をご覧ください。</p>
<toc-add-entry name=discover>セキュリティ上の問題を見つけたと思います。
これからどうすればいいのでしょう? </toc-add-entry>
<p>A: セキュリティ上の問題に関して知見を得たなら、
それがあなたのパッケージでも他の人のパッケージでも、
まずセキュリティチームに連絡してください。もし Debian
セキュリティチームが報告された問題が脆弱性であり、
他のベンダにも同じ問題があると判断したならば、
それらのベンダにはセキュリティチームから連絡します。
もしその脆弱性が未公開のものであるなら、
他のベンダと協調してセキュリティ勧告を公開するようにしますので、
主要なディストリビューションでは発表は同期したものになります。</p>
<p>その脆弱性が既に公に知られるものになっている場合は、Debian
のバグ追跡システムに報告し、"security"
というタグを付けるようにしてください。</p>
<p>あなたがもし Debian 開発者なら、<a href="#care">以下を参照</a>してください。</p>
<toc-add-entry name=care>自分のパッケージにセキュリティ上の問題を見つけた場合、
どうすればいいのでしょう? </toc-add-entry>
<p>A: セキュリティ上の問題に関して知見を得たなら、
それがあなたのパッケージでも他の人のパッケージでも、
まずセキュリティチームに連絡してください。連絡先は電子メールで
team@security.debian.org です。
セキュリティチームは、未解決のセキュリティ問題の履歴を採り、
セキュリティ問題に関してメンテナに協力ないし修正を行い、
セキュリティ勧告の公開に関して責任を持ち、security.debian.org
を維持管理しています。</p>
<p><a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
デベロッパーズリファレンス</a>には、何をすべきかに関して、
完全な記述があります。</p>
<p>セキュリティチームの事前の合意なしに、不安定版 (unstable)
以外にアップロードすることは、避けてください。混乱が生じ、
余分な仕事が必要になってしまいます。</p>
<toc-add-entry name=enofile>セキュリティ勧告の一つに記載された
パッケージをダウンロードしようとしているのですが、`file not found'
エラーになります。</toc-add-entry>
<p>A: 新しいバグ修正が security.debian.org
の古いパッケージを上書き更新することになる場合、
新パッケージがインストールされた時点で古いものは
速やかに削除される可能性が高いからです。このため、この場合には
`file not found' エラーになります。
私たちはセキュリティバグのあることが分かっているパッケージを、
本当に必要な期間以上には配布したくはありませんので。</p>
<p>最新のセキュリティ勧告記載のパッケージを用いてください。
最新の勧告は、<a href="http://lists.debian.org/debian-security-announce/";>\
debian-security-announce</a> で公表されます。そして
パッケージのアップグレードの前に単に <code>apt-get update</code>
とするのが最良のやり方です。</p>
<toc-add-entry name=upload>バグ修正ができましたので、直接
security.debian.org にアップロードしたいのですが?</toc-add-entry>
<p>A: それはできません。security.debian.org
のアーカイブはセキュリティチームが維持管理しており、
置かれるパッケージは全て承認を得たものです。
代わりに、パッチや適切なソースパッケージをセキュリティチーム
team@security.debian.org 宛に送ってください。
修正はセキュリティチームのレビュー後に、
その際に変更が加えられるかもしれませんが、アップロードされます。</p>
<p>もし、セキュリティアップロードに慣れてない、
またはパッケージが完全なものであるという 100%
の確信がない場合には、上記のやり方で incoming
ディレクトリにアップロードするのはやめてください。
セキュリティチームの壊れたパッケージを扱う際の選択肢は限られていますし、
特にパッケージがまともなバージョン番号付けをされていない場合は
できることはあまりありません。パッケージは現状では拒否できませんし、
拒否できるようにすると <abbr title="Build Daemon">buildd</abbr>
が混乱します。このため、セキュリティチームの手間を増やさないよう協力と、
上記のメールを使う方法をお願いします。</p>
<p><a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
デベロッパーズリファレンス</a>には、何をすべきかに関して、
完全な記述があります。</p>
<toc-add-entry name=ppu>バグの修正を入手しました。私が代わりに
proposed-updates にアップロードできますか?</toc-add-entry>
<p>A: 技術的には、可能です。しかし、すべきではありません。
というのは、セキュリティチームの仕事と、深刻な干渉を起こすからです。
security.debian.org のパッケージは、自動的に proposed-updates
ディレクトリにコピーされます。もし、すでにアーカイブに
同じバージョンまたは高いバージョンのパッケージがある場合には、
セキュリティアップデートはアーカイブシステムによって拒否されてしまいます。
そうすると、安定版 (stable) ディストリビューションは結局、
proposed-updates ディレクトリの「間違った」パッケージが拒否されない限り、
そのパッケージのセキュリティアップデートがない状態になってしまいます。
その代わり、セキュリティチームに連絡してください。その際、
脆弱性に関する詳細を書き、ソースファイル (つまり、diff.gz と dsc
ファイル) をメールに添付してください。</p>
<p><a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
デベロッパーズリファレンス</a>には、何をすべきかに関して、
完全な記述があります。</p>
<toc-add-entry name=SecurityUploadQueue>パッケージに問題がないことに
相当の自信があります。アップロードの手順を教えてください。</toc-add-entry>
<p>A: あなたのパッケージが問題を起こさない、すなわちバージョン番号付けは妥当で
(つまり、安定版 (stable) のバージョンより大きく、
テスト版/不安定版のバージョンより小さい)、
セキュリティ修正に関わらずパッケージの挙動に変更はなく、
正しいディストリビューション (<code>oldstable-security</code> か
<code>stable-security</code>) 向けにコンパイルされたものであり、
security.debian.org
に初めてアップロードされるものについては元のソースを含んでいて、
最新版に当てたパッチはきれいに当たっていて、
該当するセキュリティ修正のみを変更するものであり
(<code>interdiff -z</code> と <code>.diff.gz</code>
ファイルの両方のチェックを行ってください)、
少なくとも 3 回パッチの妥当性を確認済みで、<code>debdiff</code>
が何も変更箇所を指摘しないならば、security.debian.org の incoming
ディレクトリ <code>ftp://security-master.debian.org/pub/SecurityUploadQueue</code>
にファイルをアップロードしても構いません。その際、全詳細とリンクを同時に
team@security.debian.org に連絡してください。</p>
<toc-add-entry name=help>セキュリティに関するお手伝いがしたいのですが。</toc-add-entry>
<p>A: 問題を security@debian.org に報告する前に、まず調査をしてください。
パッチを提供していただければ、処理が迅速になります。
bugtraq のメールを単に転送することは避けてください。
我々も同じメールを受信していますから。
単に転送するのではなく、bugtraq で報告された事項に対する
追加情報の場合は、是非報告してください。</p>
<toc-add-entry name=proposed-updates>proposed-updates
の対象はなんでしょう?</toc-add-entry>
<p>A: このディレクトリには、Debian 安定版 (stable)
の次のリビジョンに入るであろうパッケージが含まれています。
メンテナから安定版向けのパッケージがアップロードされると、
それらは proposed-updates ディレクトリに置かれます。
安定版は安定であることを意図されていますから、
自動的な更新は行われません。
セキュリティチームは安定版への勧告を行った際、
その修正パッケージをアップロードしますが、それらはまず
proposed-updates に置かれます。2,3ヶ月おきに安定版のリリース管理者は
proposed-updates にあるパッケージを一通り調べ、
それらが安定版にふさわしいかどうかを議論します。
そしてこれらは安定版の新しいリビジョン (例えば 2.2r3 とか 2.2r4 とか)
に組み込まれます。ふさわしくないパッケージは拒否され、
proposed-updates からもなくなります。</p>
<p>(セキュリティチームではなく) メンテナによって proposed-updates/
ディレクトリにアップロードされたパッケージは、セキュリティチームによって
サポートされませんのでご注意ください。</p>
<toc-add-entry name=composing>セキュリティチームの構成を教えてください</toc-add-entry>
<p>A: Debian セキュリティチームは、<a
href="../intro/organization">数人の役員と書記</a>から構成されています。
チームへの参加者は、チーム自身が任命します。</p>
<toc-add-entry name=lifespan>セキュリティアップデートはどれくらいの期間
提供されますか?</toc-add-entry>
<p>A: セキュリティチームは、次の安定版がリリースされてから1年後まで、
安定版をサポートしようと努めます。ただし、次の次の安定版が1年以内に
リリースされた場合はその限りではありません。というのは、
同時に2つのディストリビューションをサポートすることでさえかなり難しいので、
3つのディストリビューションをサポートすることは不可能だからです。</p>
<toc-add-entry name=check>どのようにしたらパッケージの完全性をチェックできますか?</toc-add-entry>
<p>A: Release ファイルのサインを、アーカイブに使った<a
href="http://ftp-master.debian.org/ziyi_key_2006.asc";>\
公開鍵</a>で照合することで、チェックすることができます。Release
ファイルは Packages ファイルと Sources ファイルの MD5
チェックサムを含んでおり、Packages ファイルと Sources
ファイルはバイナリパッケージとソースパッケージの MD5
チェックサムを含んでいます。パッケージの完全性をチェックする方法については、
<a href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
Debian セキュリティマニュアル</a>に説明があります。</p>
<toc-add-entry name=break>セキュリティアップデート後に、
あるパッケージが壊れた場合どうすればいいですか?</toc-add-entry>
<p>A: まず始めに、なぜそのパッケージが壊れたのか、また、
それがどのようにセキュリティアップデートと関連するのかを解明してください。
その後、それが深刻な問題ならセキュリティチームに、
それほど深刻でなければ安定版 (stable) リリースマネージャに連絡してください。
何が悪いのか解明はできなくても解決方法が分かる場合も、
セキュリティチームに話してください。安定版 (stable)
リリースマネージャに話を振られるかもしれませんが。</p>
----------------------------------------------------------------