[rfr] security/audit/{advisories,faq,index,tools}.wml (+ security/audit/{maintainers,auditing}.wml)

[Kobayashi Noritada <nori1@xxxxxxxxxxxxxxxxxxxxxxx>]

小林です。

標題の 4 ファイルの訳を修正しました。
内容の把握間違いや訳として不適切な表現などがありましたら
ご指摘ください。

なお、
http://misato.debian.or.jp/ml/debian-www:06292
に全てのファイルに変更が加えられたような書き方をしましたが、
security/audit/{maintainers,auditing}.wml については、
変化がありませんでした。
したがって、この 2 ファイルに関しては
http://misato.debian.or.jp/ml/debian-www:06273
のままなのですが、
繁雑になるのを避けるため、一緒に再投稿しておきます。

-- 
|:  Noritada KOBAYASHI
|:  Dept. of General Systems Studies,
|:  Graduate School of Arts and Sciences, Univ. of Tokyo
|:  E-mail: nori1@xxxxxxxxxxxxxxxxxxxxxxx (preferable)
|:          nori@xxxxxxxxxxxxxxxxxxx

#use wml::debian::template title="セキュリティ検査のもたらした勧告"
#use wml::debian::recent_list
#use wml::debian::translation-check translation="1.5"

<p>このページでは、セキュリティ検査活動の直接的な結果としてリリースされた Debian セキュリティ勧告 (DSA) をリストアップしています。
このプロジェクトがもたらしてきた明確な効果がわかるでしょう。</p>

<ul>
<li><a href="$(HOME)/security/2002/dsa-205">DSA-205 gtetrinet</a></li>
<li><a href="$(HOME)/security/2003/dsa-326">DSA-326 orville-write</a></li>
<li><a href="$(HOME)/security/2003/dsa-327">DSA-327 xbl</a></li>
<li><a href="$(HOME)/security/2003/dsa-329">DSA-329 osh</a></li>
<li><a href="$(HOME)/security/2003/dsa-334">DSA-334 xgalaga</a></li>
<li><a href="$(HOME)/security/2003/dsa-354">DSA-354 xconq</a></li>
<li><a href="$(HOME)/security/2003/dsa-356">DSA-356 xtokkaetama</a></li>
<li><a href="$(HOME)/security/2003/dsa-359">DSA-359 atari800</a></li>
<li><a href="$(HOME)/security/2003/dsa-368">DSA-368 xpcd</a></li>
<li><a href="$(HOME)/security/2003/dsa-369">DSA-369 zblast</a></li>
<li><a href="$(HOME)/security/2003/dsa-390">DSA-390 marbles</a></li>
<li><a href="$(HOME)/security/2003/dsa-391">DSA-391 freesweep</a></li>
<li><a href="$(HOME)/security/2003/dsa-398">DSA-398 conquest</a></li>
<li><a href="$(HOME)/security/2003/dsa-400">DSA-400 omega-rpg</a></li>
<li><a href="$(HOME)/security/2003/dsa-405">DSA-405 xsok</a></li>
<li><a href="$(HOME)/security/2004/dsa-420">DSA-420 jitterbug</a></li>
<li><a href="$(HOME)/security/2004/dsa-430">DSA-430 trr19</a></li>
<li><a href="$(HOME)/security/2004/dsa-432">DSA-432 crawl</a></li>
<li><a href="$(HOME)/security/2004/dsa-445">DSA-445 lbreakout2</a></li>
<li><a href="$(HOME)/security/2004/dsa-446">DSA-446 synaethesia</a></li>
<li><a href="$(HOME)/security/2004/dsa-447">DSA-447 hsftp</a></li>
<li><a href="$(HOME)/security/2004/dsa-451">DSA-451 xboing</a></li>
<li><a href="$(HOME)/security/2004/dsa-462">DSA-462 xitalk</a></li>
<li><a href="$(HOME)/security/2004/dsa-468">DSA-468 emil</a></li>
<li><a href="$(HOME)/security/2004/dsa-472">DSA-472 fte-console</a></li>
<li><a href="$(HOME)/security/2004/dsa-484">DSA-484 xonix</a></li>
<li><a href="$(HOME)/security/2004/dsa-508">DSA-508 xpcd</a></li>
<li><a href="$(HOME)/security/2004/dsa-509">DSA-509 gatos</a></li>
<li><a href="$(HOME)/security/2004/dsa-510">DSA-510 jftpgw</a></li>
</ul>

#use wml::debian::template title="検査を実施するには"
#use wml::debian::recent_list
#use wml::debian::translation-check translation="1.6"


<p>このページでは、パッケージの検査を実施する際に必要となる手順の概要を示します。</p>

<p>最初の一歩は、検査するパッケージを実際に選択することです。
あなたは、セキュリティがより重要とされるパッケージを選ぶべきです。</p>
<p>意志決定方法に関する私たちの提案については、<a href="$(HOME)/security/audit/packages">\
検査対象として最も重要だと私たちが考えるパッケージのリスト</a>を見てみてください。</p>
<p>一つだけ明記しておくべきことがあります。
私たちは、パッケージを一度だけ検査したことを確認しようとしている<i>のではありません</i>。
多くの人々が同じパッケージを選んで検査すれば、それはよい仕事になります。
というのは、
パッケージはセキュリティに気を配る必要がある (security sensitive) と多くの人々が信じているということを実証するからです。</p>
<p>パッケージを本質的に無作為に選んでもらうことで、私たちは調整作業を簡略化できます。
さらに「どのようにしてあなたは、X さんがよい仕事をすると確信できるのか ?」という問題も取り除くことができます
(遅かれ早かれ誰か他の人が同じプログラムを選んで検査するでしょうから、私たちは確信する必要はないのです)。</p>

<h2>検査を始めるには</h2>
<p>パッケージの選択が終わったら、実際に検査を始める必要があります。</p>
<p>どんな種類の問題を探せばよいのか確信がもてなかったら、
安全なソフトウェアの開発方法に関する本をまず読むことから始めてください。</p>
<p><a href="http://www.dwheeler.com/secure-programs";>Secure Programming for Linux and Unix HOWTO</a> にはあなたの役に立つよい情報が大量に載っています (訳注: <a href="http://www.linux.or.jp/JF/JFdocs/Secure-Programs-HOWTO/";>オンラインバージョンの日本語訳</a>もあります)。</p>

<p>不完全ではありますが、ツールは、脆弱性らしいものを見つけるときにはやはり非常に役に立ちます。
利用できる検査ツールの一部およびそれらの使い方に関しては、
より詳しくは<a href="tools">検査ツールのページ</a>を見てください。</p>
<p>コード自体を見るのと同様に、パッケージの付属文書を読んでみるのもよい考えです。
そしてインストールして使ってみてください。</p>
<p>こういったことによってあなたは、
標準的な操作でそのプログラムの機能を失わせる方法を考え出せるかもしれません。</p>



<h2>問題を報告するには</h2>
<p>検査中のパッケージ内に実際に問題を発見したら、あなたはそれを報告するべきです。</p>
<p>一般的に、セキュリティ上のバグは、修正されるまで公開されるべきではありません。
したがって、標準的な <a href="http://bugs.debian.org/";>Debian バグ追跡システム</a>を使った報告は<i>しないでください</i>。
代わりに、
更新パッケージのリリースを担当する<a href="$(HOME)/security/">セキュリティチーム</a>に問題を直接報告してください。</p>
<p>理想的には、それぞれの報告には発見された問題に関する修正方法も含まれるべきです。
修正方法とは、実際にテストされ問題を実際に解決することが確認されているものです。</p>
<p>もし修正方法がわからなかったら、問題の有効範囲に関してなるべく詳しく報告してください。
問題の相対的な重要度やいくらかの次善策が報告できるとよりよいでしょう。</p>
<p>セキュリティチームは、必要なら他の Linux ディストリビューションと協調し、
あなたの代わりにパッケージのメンテナと連絡をとってくれるでしょう。</p>

#use wml::debian::template title="Debian セキュリティ検査 FAQ"
#use wml::debian::toc
#use wml::debian::translation-check translation="1.11"

<p>このページでは、このプロジェクトについて初めて耳にした人がもつと予想される、
代表的な質問の一部をリストアップします。</p>

<toc-display>

<toc-add-entry name="what">Debian セキュリティ検査プロジェクトとは何ですか?</toc-add-entry>
<p>Debian セキュリティ検査プロジェクトは、
Debian プロジェクト内で行われている小さなプロジェクトです。
Debian ユーザが利用できるパッケージのソースコード検査を実施することで、
セキュリティに対して積極的な姿勢をとろうと計画されました。</p>
<p>検査では、Debian 安定版 (stable) ディストリビューションを対象として、
<a href="packages">パッケージの優先順位に関するガイドライン</a>によって方向づけられている検査作業を行います。</p>

<toc-add-entry name="start">Debian セキュリティ検査プロジェクトはいつ始められたのですか?</toc-add-entry>
<p>最初の勧告は 2002 年 12 月にリリースされ、それから長い時間をかけて一連の勧告が追加されてきました。</p>
<p>活動は非公式な立場で続けられましたが、
2004 年 5 月 に Debian プロジェクトリーダーの Martin Michlmayr さんによって「公式」の地位を認められました。</p>

<toc-add-entry name="advisories">どの勧告が、検査活動の結果として得られたものなのですか?</toc-add-entry>
<p>検査作業の一環としてリリースされた勧告は多数あります。
プロジェクトが公式の地位を与えられる前にリリースされたものは全て、
<a href="advisories">検査のもたらした勧告のページ</a>にリストアップされています。</p>
<p>近い将来には、
公式の地位を得た後にプロジェクトから出され公に知られた勧告が、
Debian セキュリティ勧告のレポートを見たり「Debian セキュリティ勧告プロジェクト」で検索したりして見つけられるようになると期待されます。</p>

<toc-add-entry name="credit">誰がこの仕事に貢献してきたのですか?</toc-add-entry>
<p>Steve Kemp さんが初期の処理過程を編成することで Debian セキュリティ検査プロジェクトを始め、
多数の脆弱性を発見してこのプロジェクトを試しました。</p>
<p>Ulf H&auml;nhammar さんが、初期のこの非公式な期間にプロジェクトに参加し、いくつかの脆弱性を発見しました。
それらの脆弱性はその後に修正されています。
Ulf さんの後まもなく Jaguar さんもまたいくつかの重大なセキュリティ問題を発見しました。</p>
<p><a href="http://www.dwheeler.com";>David A. Wheeler</a> さんが、
この活動を Debian の公式なプロジェクトとして率いることを申し出るよう Steve Kemp さんに言い、
それは Debian プロジェクトリーダーの Martin Michlmayr さんが関与することによって可能となりました。
David さんはまた、セキュリティ検査プロジェクトのウェブページの中身に関して多数の有益な提案をし、複数のセクションに直接的な貢献をしました。</p>
<p><a href="http://www.debian.org/security";>Debian セキュリティチーム</a>が、
見つけられたあらゆる脆弱性を速やかに修正して世界中に配布する作業を確実にすることで、検査を成功させる上で大きな手助けをしました。</p>
<p>私たちは、貢献してくれる人がさらにいたらいつでも歓迎します!</p>


<toc-add-entry name="contribute">私はどのように貢献できますか?</toc-add-entry>
<p>パッケージの検査に必要な時間や技術力をもっているのなら、あなたは単純に検査に着手すればよいのです!</p>
<p><a href="auditing">検査方法の概要</a>を読めば、仕事を始める方法がよくわかるはずです - さらに質問があれば、<a href="http://shellcode.org/mailman/listinfo/debian-audit";>debian-audit メーリングリスト</a>で訊くとよいでしょう。</p>

<toc-add-entry name="maintainer">私はパッケージのメンテナとしてどのように貢献できますか?</toc-add-entry>
<p>パッケージのメンテナは、
コードそのものに一通り目を通すか手助けを求めるかして、
自分がパッケージするソフトウェアのセキュリティを確実なものにする手助けをできます。</p>
<p><a href="maintainers">パッケージのメンテナ向けの検査方法</a>の概要を見てください。</p>

<toc-add-entry name="reporting">自分が発見した問題をどのように報告したらよいのですか?</toc-add-entry>
<p><a href="$(HOME)/security/faq">セキュリティチームの FAQ</a> に、その方法を記述したセクションがあります。</p>

<toc-add-entry name="clean">検査されてセキュリティ面に問題がないとわかったパッケージが利用できるのですか?</toc-add-entry>
<p>いいえ、これまでに検査を受けて内部に問題が見つからなかったパッケージは、公にはリストアップされていません。</p>
<p>その一つの理由は、見落とされた問題が潜んでいるかもしれないことにあり、
また別の理由は、細かい調整を受けずに複数の人々で検査が行われることにあります。</p>

<toc-add-entry name="moreinfo">さらに詳しい情報をどこで得られますか?</toc-add-entry>
<p>あなたが購読したり質問をしたりできるメーリングリストがあります。</p>
<p>さらに詳しくは <a href="http://shellcode.org/mailman/listinfo/debian-audit";>debian-audit メーリングリストのページ</a>を見てください。</p>

#use wml::debian::template title="Debian セキュリティ検査プロジェクト"
#use wml::debian::recent_list
#use wml::debian::translation-check translation="1.11"

<p>Debian セキュリティ検査プロジェクトは、
セキュリティ問題を探すため Debian パッケージを検査することに重点的に取り組むプロジェクトです。</p>
<p>短い期間にプロジェクトはいくつかの <a href="$(HOME)/security/">Debian セキュリティ勧告</a>に関わり、
Debian のセキュリティを向上する上でこの検査活動が本当に機能することを示してきました。
今後の活動からさらに多くの勧告がもたらされることが期待されます。</p>
<p>コードの検査を積極的に行なう姿勢をとることで、
私たちは、Debian がセキュリティを重要視する長い歴史がこれからも続いていくのを助けることができます。</p>


<h2>検査の範囲</h2>
<p>プロジェクトの目的は、
Debian 安定版 (stable) リリース中のパッケージのなるべく多くについて、
潜在的な欠陥を探すため検査することにあります。
安全でないパッケージが安定版 (stable) リリースに入る可能性自体をそもそも減らす目的で、
不安定版 (unstable) ディストリビューション中に含まれる重要なパッケージについてもまた、
欠陥を探すため検査するかもしれません。</p>
<p>現在の Debian リリースの完全なサイズは非常に大きいため、
小さいチームですべてのパッケージを検査するのは実行不可能です。
そのため、よりセキュリティに気を配る必要がある (security sensitive) パッケージを優先するシステムがあります。</p>
<p><a href="packages">パッケージの優先順位に関するガイドライン</a>は、
重要なパッケージの検査作業に対して確実に時間をかけようという試みです。
また<a href="tools">検査ツールの概要</a>では、
入手可能ないくつかのソースコードスキャナを使うとどのような検査ができるかを説明しています。</p>

<h2>これまでにリリースされた勧告</h2>
<p>セキュリティ問題に対して脆弱だとわかったパッケージに関しては、
Debian セキュリティチームによって <a href="$(HOME)/security/">DSA</a> がリリースされます。</p>
<p>参考のため、セキュリティ検査の過程を通じて直接もたらされた<a href="advisories">これまでの勧告のリスト</a>もあります。</p>

<h2>さらに詳しい情報</h2>
<p>プロジェクトに関するさらに詳しい情報は<a href="faq">セキュリティ検査の FAQ</a> で見つけることができます。</p>


#use wml::debian::template title="パッケージのメンテナ向けの検査方法"
#use wml::debian::recent_list
#use wml::debian::translation-check translation="1.4"

<p>Debian アーカイブに含まれるパッケージのメンテナをしている方は、
自分の担当するコードに一通り目を通すことを考慮に入れてください。</p>

<p>ソースコード検査ツールを利用できればこの作業はかなり楽になります。
時間がなくて自分で徹底的な検査をできなくても、問題がある可能性を秘めた箇所を見つけることができます。</p>

<p>もし手助けが必要なら、
<a href="http://shellcode.org/mailman/listinfo/debian-audit";>debian-audit メーリングリスト</a>に参加して、
あなたのパッケージに一通り目を通すようボランティアに頼むことを考えてみてください。</p>
 
<h2>新しいリリース</h2>
<p>気の利くメンテナの一人として、
あなたは自分のパッケージの上流の新しいリリースに注意を向けておくべきです。
changelog にセキュリティ問題に関する記述があったら、
あなたのもつ安定版 (stable) ディストリビューションのコードが脆弱性を含むものでないか調べてみましょう。</p>
<p>不安定版 (unstable) ディストリビューションで利用できる脆弱性を含むバージョンをもっていたら、
<a href="/security/faq">セキュリティチームの FAQ に</a>書かれているようにセキュリティチームに連絡をとってください。</p>

#use wml::debian::template title="セキュリティ検査ツール"
#use wml::debian::recent_list
#use wml::debian::translation-check translation="1.6"

<p>Debian アーカイブに含まれる、
ソースコードの検査を目的として作られたいくつかのパッケージを利用できます。
それらには以下のようなものがあります:</p>

<ul>
<li><a href="http://packages.debian.org/flawfinder";>Flawfinder</a></li>
<li><a href="http://packages.debian.org/its4";>ITS4</a></li>
<li><a href="http://packages.debian.org/rats";>RATS</a></li>
<li><a href="http://packages.debian.org/pscan";>pscan</a></li>
</ul>

<p>どのツールも完全ではなく、より精密な調査のためのガイドラインとして使えるにすぎません。
しかし、これらのツールが非常に使いやすいことを考えると、時間を割いて実際に使ってみる価値はあります。</p>
<p>各々のツールには異なる長所と短所があるので、二つ以上使うことをお勧めします。</p>

<h2>Flawfinder</h2>
<p>flawfinder は Python で書かれたツールで、C や C++ のソースコードを分析してセキュリティ上の潜在的な欠陥を探すために作られています。</p>
<p>このツールをソースコードの入ったディレクトリに対して実行することで、
検出された潜在的な問題が危険度 (<i>risk</i> の項目に 1-5 の整数値が入ります。) でソートされてレポートとして出力されます。
危険度の低いものを無視するために、
特定の危険度レベルに満たない欠陥に関してはレポートに入れないよう、プログラムを設定することが可能です。
出力は、デフォルトではプレーンテキストとなりますが、HTML でのレポートも利用できます。</p>
<p>このプログラムは、コードをスキャンし、
よく悪用される関数のデータベースに含まれる関数を利用する箇所を探すことで機能します。</p>
<p>レポートを読むのを助けるために、出力されるレポートに関数が使われている行を含ませることができます。
これを利用すると、その関数が問題であると速やかに見抜いたりその関数を素早く考慮から外したりできます。</p>
<!-- TODO : Link to example page -->

<h2>ITS4</h2>
<p>ITS4 は non-free のツールで、C と C++ の両方のコードをスキャンして潜在的なセキュリティホールを探すのに使うことができます。</p> 
<p>危険な関数の呼び出しが注意深く行われている場合の一部に対しては警告しないなど、
このツールは気の利いた出力をしようとします。</p>
<!-- TODO : Link to example page -->

<h2>RATS</h2>
<p>RATS は、遥かに広範囲の言語がサポートされていることを除けば、
上にリストアップしたものと同様のツールです。
このツールが現在サポートしているのは C, C++, Perl, PHP, Python です。</p>
<p>このツールは、脆弱性に関する情報を読み出すのに単純な XML ファイルを使うので、
最も更新しやすいツールの一つとなっています。
サポートされている各々の言語について新しい機能を加えることが容易にできます。</p>
<!-- TODO : Link to example page -->

<h2>pscan</h2>
<p>pscan は他のツールとは異なり、多目的スキャナでないと説明されます。
その代わり、これはフォーマット文字列バグの検出という目的に特化しています。</p>
<p>このツールは、<tt>printf</tt>, <tt>fprintf</tt>, <tt>syslog</tt> などの可変数引数関数を C や C++ のソースコード内で使うときに発生しうる潜在的な問題を見つけようとします。</p>
<p>フォーマット文字列バグは、検出や修正をかなり容易にできます。
このバグは、ソフトウェア攻撃としては最新の部類に入るものに利用されますが、
おそらく大部分は既に見つけられ修正されています。</p>
<!-- TODO : Link to example page -->


<h2>スキャナの出力を理解する</h2>
<p>各々の汎用スキャニングツールの出力には、
検出された欠陥の説明が (そしておそらくコードの修正方法に関するアドバイスも) 含まれるでしょう。</p>
<p>例えば次の文章は、<tt>getenv</tt> の危険性を記述する RATS の出力を抜き出してきたものです:</p>
<p>&quot;環境変数は非常に信頼性に欠ける入力です。
それらは、どんな長さにすることも、どんなデータを含ませることもできます。
データの中身や長さに関して全く仮定を置かないでください。
環境変数を使わずに済ませることが可能なら不必要な部分を削除し、
環境変数が必要なら適度な長さで切り捨ててください。&quot;</p>
<p>レポートに書かれたセキュリティホールの修正方法に関してさらなるアドバイスが必要だと感じるなら、
あなたは、安全なプログラムの書き方に関する本 (例えば David A. Wheller さんが書いた <a href="http://www.dwheeler.com/secure-programs/";>Secure Programming for Linux and Unix HOWTO</a>) で勉強するべきです (訳注: <a href="http://www.linux.or.jp/JF/JFdocs/Secure-Programs-HOWTO/";>オンラインバージョンの日本語訳</a>もあります)。</p>
<p>(セキュリティ問題を報告する際に、そのセキュリティホールを閉じるためのパッチがあると大いに感謝されることを覚えておいてください。)</p>