Merge the following from the English version:

www/ja/security/security.html 1.150 -> 1.179
svn path=/www/; revision=35641
2010-04-11 04:17:15 +00:00 · 2010-04-11 04:17:15 +00:00 · d63224e4b4 · 2020-12-08 03:00:23 +00:00
commit d63224e4b4
parent 137d50e8d0
1 changed files with 108 additions and 412 deletions
--- a/ja/security/security.sgml
+++ b/ja/security/security.sgml
@ -1,13 +1,14 @@
 <!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
 <!ENTITY base CDATA "..">
-<!ENTITY date "$FreeBSD: www/ja/security/security.sgml,v 1.84 2005/10/04 16:21:53 hrs Exp $">
-<!ENTITY title "FreeBSD Security Information">
+<!ENTITY date "$FreeBSD: www/ja/security/security.sgml,v 1.85 2006/08/19 21:24:49 hrs Exp $">
+<!ENTITY title "FreeBSD セキュリティ情報">
 <!ENTITY % navinclude.support "INCLUDE">
+<!ENTITY % developers SYSTEM "../../en/developers.sgml"> %developers;
 <!ENTITY advisories.html.inc SYSTEM "advisories.html.inc">
 ]>
-<!-- $FreeBSD: www/ja/security/security.sgml,v 1.84 2005/10/04 16:21:53 hrs Exp $ -->
+<!-- $FreeBSD: www/ja/security/security.sgml,v 1.85 2006/08/19 21:24:49 hrs Exp $ -->
 <!-- The FreeBSD Japanese Documentation Project -->
-<!-- Original revision: 1.150 -->
+<!-- Original revision: 1.179 -->

 <html>
    &header;
@ -27,15 +28,28 @@ OS

 <H2>目次</H2>
 <UL>
+<li><a href="#how">FreeBSD セキュリティ問題の報告方法と連絡先について</a></li>
 <LI><A HREF="#sec">FreeBSD セキュリティオフィサについて</A></LI>
+<li><a href="&enbase/security/charter.html">セキュリティオフィサおよびチームの憲章</a></li>
 <LI><A HREF="#pol">情報の取り扱いに関する方針</A></LI>
 <LI><A HREF="#adv">FreeBSD のセキュリティ勧告</A></LI>
-<LI><A HREF="#ml">FreeBSD セキュリティメーリングリストについて</A></LI>
-<LI><A HREF="#tat">FreeBSD セキュリティの Tips と Tricks</A></LI>
-<LI><A HREF="#spg">安全なプログラミングのためのガイドライン</A></LI>
-<LI><A HREF="#misc">その他の関連するセキュリティ情報</A></LI>
+<li><a href="http://www.freebsd.org/handbook/security-advisories.html">
+FreeBSD セキュリティ勧告の読み方</a></li>
 </UL>

+<a name="how"></a>
+<p>FreeBSD に関わるすべてのセキュリティ問題は、個人的に
+<a href="mailto:security@FreeBSD.org">セキュリティオフィサチーム</a>、
+または <a href="mailto:security-officer@FreeBSD.org">
+セキュリティオフィサ</a> に直接 (英語で) 報告してください。
+報告には少なくとも以下を含める必要があります。 <br><br>
+脆弱性の詳細、<br>
+可能であれば影響範囲 (FreeBSD のどのバージョンが影響するか)、<br>
+回避方法、<br>
+可能であればコードの例。<br></p>
+
+<p>問題の報告後、セキュリティオフィサまたはセキュリティオフィサチーム代表からの返信があります。</p>
+
 <A NAME=sec></A>
 <H2>FreeBSD セキュリティオフィサとセキュリティオフィサチーム</H2>

@ -45,49 +59,49 @@ FreeBSD
 <P>もしセキュリティに関するバグの可能性について
 FreeBSD プロジェクトと連絡をとる必要が生じたら、
 発見したことの詳細と、何が問題となっているのかを書いて
-<a HREF="mailto:security-officer@FreeBSD.org">セキュリティオフィサ</a>に
-メールを送ってください。</P>
+<a HREF="mailto:security-officer@FreeBSD.org">セキュリティオフィサ</a>
+にメールを送ってください。</P>

 <P>FreeBSD プロジェクトでは、脆弱性の報告に対して臨機応変に対応する目的で
 セキュリティオフィサのメールエイリアスに 4 人
-(セキュリティオフィサ、セキュリティオフィサ補佐、コアチームメンバ 2 人)
+(セキュリティオフィサ、名誉セキュリティオフィサ、セキュリティオフィサ補佐、コアチームメンバ 1 人)
 が登録されています。つまり、
 <a href="mailto:security-officer@FreeBSD.org">&lt;security-officer@FreeBSD.org&gt;</a>
 へ送られたメールは、現在以下のメールアドレスへ届くようになっています。</P>

 <table>
 <tr valign="top">
-  <td>Jacques Vidrine <a
-    href="mailto:nectar@FreeBSD.org">&lt;nectar@FreeBSD.org&gt;</a></td>
+  <td>&a.cperciva; <a
+    href="mailto:cperciva@FreeBSD.org">&lt;cperciva@FreeBSD.org&gt;</a></td>
  <td>セキュリティオフィサ</td>
 </tr>
 <tr valign="top">
-  <td>Chris Faulhaber <a
-    href="mailto:jedgar@FreeBSD.org">&lt;jedgar@FreeBSD.org&gt;</a></td>
+  <td>&a.nectar; <a
+    href="mailto:nectar@FreeBSD.org">&lt;nectar@FreeBSD.org&gt;</a></td>
+  <td>名誉セキュリティオフィサ</td>
+</tr>
+<tr valign="top">
+  <td>&a.simon; <a
+    href="mailto:simon@FreeBSD.org">&lt;simon@FreeBSD.org&gt;</a></td>
  <td>セキュリティオフィサ補佐</td>
 </tr>
 <tr valign="top">
-  <td>Robert Watson <a
+  <td>&a.rwatson; <a
    href="mailto:rwatson@FreeBSD.org">&lt;rwatson@FreeBSD.org&gt;</a></td>
-  <td>FreeBSD コアチームメンバ、リリースエンジニアリング渉外、<br>
+  <td>FreeBSD コアチーム渉外、リリースエンジニアリング渉外、<br>
      TrustedBSD プロジェクト渉外、システムセキュリティアーキテクチャの専門家</td>
 </tr>
-<tr valign="top">
-  <td>Warner Losh <a
-    href="mailto:imp@FreeBSD.org">&lt;imp@FreeBSD.org&gt;</a></td>
-  <td>FreeBSD コアチーム渉外、名誉セキュリティオフィサ</td>
-</tr>
 </table>

 <P>また、セキュリティオフィサが選出したコミッターグループである
-<a href="mailto:security-team@FreeBSD.org">セキュリティオフィサチーム
-&lt;security-team@FreeBSD.org&gt;</a> が、
+<a href="mailto:security@FreeBSD.org">セキュリティオフィサチーム
+&lt;security@FreeBSD.org&gt;</a> が、
 セキュリティオフィサをサポートしています。</P>

 <p>セキュリティオフィサ宛のメッセージに暗号化が必要な場合には、
 セキュリティオフィサの
 <a href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/public_key.asc">PGP
-公開鍵</a>を使って暗号化してください。</p>
+公開鍵</a> を使って暗号化してください。</p>

 <a NAME="pol"></a>
 <h2>情報の取り扱いに関する方針</h2>
@ -100,7 +114,7 @@ FreeBSD
 <p>セキュリティオフィサは、
 FreeBSD プロジェクトの資源を脅かすような緊急性の高い脆弱性を
 <a href="mailto:admins@FreeBSD.org">FreeBSD
-クラスタ管理者</a>の一人ないし複数の人たちに<em>かならず</em>通知します。</p>
+クラスタ管理者</a> の一人ないし複数の人たちに<em>かならず</em>通知します。</p>

 <p>セキュリティオフィサは、
 問題を完全に理解したり修正するために専門的知識や意見が必要とされる場合、
@ -121,7 +135,7 @@ FreeBSD
 リリースエンジニアに脆弱性の情報を提供しない場合もあります。</p>

 <p>FreeBSD セキュリティオフィサは、FreeBSD とコードを共有しているサードパーティベンダ
-(OpenBSD および NetBSD プロジェクト、Apple、FreeBSD に由来するソフトウェアのベンダ、
+(OpenBSD, NetBSD および DragonFlyBSD プロジェクト、Apple, FreeBSD に由来するソフトウェアのベンダ、
 Linux ベンダのセキュリティリスト) はもちろんのこと、
 他の団体や CERT
 (訳注: 日本では <A HREF="http://www.jpcert.or.jp/">JPCERT/CC</a>)
@ -144,16 +158,6 @@ FreeBSD
 セキュリティオフィサはユーザコミュニティの安全を最大限に確保するため、
 報告者の指定した公開スケジュールを無視する可能性があることに注意してください。</p>

-<p>報告者は
-FreeBSD プロジェクトがオープンソースプロジェクトだということ、
-また、FreeBSD のソースツリーに加えられたあらゆる変更が
-記録されているリビジョン管理情報は、世界中からアクセス可能であるということに
-注意してください。
-公開スケジュールの指定は、セキュリティ勧告、修正パッチ、更新情報の公開に加え、
-ソースツリーへの最初の修正も考慮したものである必要があります。
-なお、セキュリティ勧告、修正パッチ、バイナリアップデートの生成にはリビジョン管理システムが利用されるため、
-ツリーへの修正とこれらの作業の間には必然的に時間的な遅れが生じます。</p>
-
 <p>情報を提供する際は、PGP を使って暗号化しても構いません。
 また、その旨を明記すれば、それに対する返信も PGP を用いて暗号化されます。</p>

@ -174,56 +178,98 @@ FreeBSD
 -STABLE ブランチには
 <TT>RELENG_4</TT> のような CVS タグ名が付けられています。
 これに対応する構築物は
-<TT>FreeBSD 4.6-STABLE</TT> のような名前になります。</P></LI>
+<TT>FreeBSD 4.10-STABLE</TT> のような名前になります。</P></LI>

 <LI><P>FreeBSD の各リリースには、
 対応するセキュリティブランチがひとつ用意されています。
 セキュリティブランチには
-<TT>RELENG_4_6</TT> のような CVS タグ名が付けられています。
+<TT>RELENG_4_10</TT> のような CVS タグ名が付けられています。
 これに対応する構築物は
-<TT>FreeBSD 4.6-RELEASE-p7</TT> のような名前になります。</P></LI>
+<TT>FreeBSD 4.10-RELEASE-p5</TT> のような名前になります。</P></LI>

 </UL>

-<P>各ブランチに対するセキュリティオフィサのサポートには、
-「原則としてリリース後 12 ヵ月間」という期限があります。
-現在サポートされているブランチの保守終了予定日は、次のとおりです。
-<EM>保守終了予定日</EM>の列には、
+<P>Ports Collection に関連した問題は、
+<A HREF="http://vuxml.FreeBSD.org/">FreeBSD VuXML</A> により提供されます。</P>
+
+<P>各ブランチに対するセキュリティオフィサのサポートには期限があります。
+サポート期間には 3 種類あり、各ブランチに対して
+<EM>Early adopter</EM>', `<EM>Normal</EM>', そして `<EM>Extended</EM>'
+のどれかが割り当てられます。
+この割り当ては、ブランチの保守終了日を決定する際のガイドラインとして利用されます。</P>
+
+<DL>
+  <DT>Early adopter</DT>
+  <DD>-CURRENT ブランチからのリリースが対象です。
+    セキュリティオフィサによって、リリース後最低 6 ヵ月間サポートされます。</DD>
+  <DT>Normal</DT>
+  <DD>-STABLE ブランチからのリリースが対象です。
+    セキュリティオフィサによって、リリース後最低 12 ヵ月間サポートされます。</DD>
+  <DT>Extended</DT>
+  <DD>選ばれたリリースが対象です。
+    セキュリティオフィサによって、リリース後最低 24 ヵ月間サポートされます。</DD>
+</DL>
+
+<P>現在サポートされているブランチの分類および保守終了予定日は、次のとおりです。
+<EM>保守終了予定日</EM> の列には、
 そのブランチに対応する最も早い保守終了予定日が記入されています。ただし、
-これらの予定日は延長される可能性があること、また、そうするにふさわしい理由があれば
-ブランチの保守が記載されている日付よりも早く終了する可能性もあるということに
-ご注意ください。</P>
+これらの予定日は延長される可能性があること、また、そうするにふさわしい理由があれば、
+ブランチの保守が記載されている日付よりも早く終了する可能性もあるということにご注意ください。</P>
+
+<!--
+    Please also update www/en/releng/index.sgml when updating this
+    list of supported branches.
+-->

 <table class="tblbasic">
 <TR>
  <TH>ブランチ</TH>
  <TH>リリース</TH>
+  <TH>分類</TH>
+  <TH>リリース日</TH>
  <TH>保守終了予定日</TH>
 </TR>
 <TR>
  <TD>RELENG_4</TD>
  <TD>なし</TD>
-  <TD>2004 年 10 月 31 日</TD>
+  <TD>なし</TD>
+  <TD>なし</TD>
+  <TD>2007 年 1 月 31 日</TD>
 </TR>
 <TR>
-  <TD>RELENG_4_8</TD>
-  <TD>4.8-RELEASE</TD>
-  <TD>2004 年 3 月 31日</TD>
+  <TD>RELENG_4_10</TD>
+  <TD>4.10-RELEASE</TD>
+  <TD>Extended</TD>
+  <TD>2004 年 5 月 27 日</TD>
+  <TD>2006 年 5 月 31 日</TD>
 </TR>
 <TR>
-  <TD>RELENG_4_9</TD>
-  <TD>4.9-RELEASE</TD>
-  <TD>2004 年 10 月 31日</TD>
+  <TD>RELENG_4_11</TD>
+  <TD>4.11-RELEASE</TD>
+  <TD>Extended</TD>
+  <TD>2005 年 1 月 25 日</TD>
+  <TD>2007 年 1 月 31 日</TD>
 </TR>
 <TR>
-  <TD>RELENG_5_1</TD>
-  <TD>5.1-RELEASE</TD>
-  <TD>2004 年 2 月 28 日</TD>
+  <TD>RELENG_5</TD>
+  <TD>なし</TD>
+  <TD>なし</TD>
+  <TD>なし</TD>
+  <TD>2007 年 5 月 31 日</TD>
 </TR>
 <TR>
-  <TD>RELENG_5_2</TD>
-  <TD>5.2-RELEASE</TD>
-  <TD>2004 年 7 月 31 日</TD>
+  <TD>RELENG_5_3</TD>
+  <TD>5.3-RELEASE</TD>
+  <TD>Extended</TD>
+  <TD>2004 年 11 月 6 日</TD>
+  <TD>2006 年 10 月 31 日</TD>
+</TR>
+<TR>
+  <TD>RELENG_5_4</TD>
+  <TD>5.4-RELEASE</TD>
+  <TD>Normal</TD>
+  <TD>2005 年 5 月 9 日</TD>
+  <TD>2006 年 5 月 31 日</TD>
 </TR>
 </TABLE>

@ -231,13 +277,6 @@ FreeBSD
 積極的にメンテナンスされることはありませんので、
 上記のサポートされているリリースのいずれかへのアップグレードを強く推奨します。</P>

-<P>セキュリティに関する修正は FreeBSD の開発と同様に、まず
-<A HREF="&enbase;/doc/ja_JP.eucJP/books/handbook/cutting-edge.html#CURRENT">FreeBSD-current</A>
-ブランチに導入されます。
-そして数日間のテストを経て、わたしたちのカバーしている
-FreeBSD-stable ブランチに対応するように修正内容が持ち込まれ、
-勧告が公表されることになります。</P>
-
 <P>2002 年に発行された勧告に関する統計情報:</P>
 <ul>
 <li>ベースシステムに関するセキュリティ勧告は、(さまざまな緊急度のものが) 44 発行されました。</li>
@ -288,349 +327,6 @@ Ports Collection

 &advisories.html.inc;

-<A NAME=ml></A>
-<H2>FreeBSD のセキュリティメーリングリストについて</H2>
-
-<P>もしいくつかの FreeBSD システムを管理/利用しているのなら、
-以下のメーリングリストのうち少なくとも一つに参加するべきです:</P>
-
-<TABLE>
-<TR>
-<TD><A HREF="http://lists.freebsd.org/mailman/listinfo/freebsd-security">freebsd-security</A></TD>
-<TD>セキュリティ一般に関する議論</TD>
-</TR>
-<TR>
-<TD><A HREF="http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications">freebsd-security-notifications</A></TD>
-<TD>セキュリティ告知 (流量の少ないモデレートメーリングリスト)</TD>
-</TR>
-</TABLE>
-
-<A NAME=spg></A>
-<H2>安全なプログラミングのためのガイドライン</H2>
-<P></P><UL>
-<LI>いかなる場合も入力の源 (source of input) を信用しないでください。
-例えばコマンドライン引数、環境変数、設定ファイル、入ってくる TCP/UDP/ICMP
-パケット、ホスト名の lookup、関数の引数などです。
-もし受け取ったデータの長さ、内容が自分の制御下にないなら、
-内容をコピーするプログラム、関数は十分に注意しなければなりません。
-特に注意しなければならないのは以下のようなことです:
-<P></P>
-  <UL>
-
-<LI>境界のわからないデータによる strcpy() や sprintf() の呼び出し。
-長さが分かっている場合には strncpy や snprintf() を使います。
-(長さが分からない場合には何らかの境界チェックを実装します。)
-要するに、gets() や sprintf() は決して使ってはいけない、ということです、以上。
-もし使ったとしたら、邪悪な小人があなたの後ろから忍び寄ることでしょう。
-<P></P></LI>
-
-<LI>もし特定の文字を禁止したユーザの入力を必要とした場合には、
-決してそれらの禁止した文字をチェックしてはいけません。
-代りに、あなたが許可した文字でのみ構成されているかどうかを
-チェックします。 基本的には、明示的に許可したもの以外は
-すべて禁止する、とします。
-<P></P></LI>
-
-<LI>strncpy() と strncat() のマニュアルページを良く読むこと。
-これらがどのように働くのか良く理解してください!!!
-strncpy() が末端の \0 を付け加えないかもしれないのに対して、
-strncat() は \0 を付け加えます。
-<P></P></LI>
-
-<LI>strvis() と getenv() の誤用に注意する。
-strvis() では、コピー先の文字列を簡単に駄目にしてしまいます。
-getenv() はプログラムが予想する長さよりも長い文字列を返すことがあります。
-これらの二つの関数は、プログラムへの攻撃に際し鍵となる手法のひとつで、
-環境変数に予想外の値を設定しスタックや変数を上書きします。
-もしあなたのプログラムが環境変数を読み込むなら、偏執症になってください。
-しつこいくらいの偏執症に。
-<P></P></LI>
-
-<LI>open() や stat() を使うときは、毎回自問自答してください:
-「これがシンボリックリンクだったらどうなる？」
-<P></P></LI>
-
-<LI>mktemp()、tempnam() などの代りに mkstemp() を使うようにする。
-一般的に /tmp で起こる競合に注意することはもちろんのこと、
-めったに起こらない状況にも注意を払ってください:
-	<UL>
-	<LI>ディレクトリを作成する。 これは成功も失敗も有り得る。</LI>
-	<LI>O_CREAT | O_EXCL でファイルをオープンする</LI>
-	</UL>
-mkstemp() を使った場合、これらのケースもうまく面倒を見てくれます。
-よってすべての一時的なファイルは、競合条件を排除し、
-パーミッションが適切かどうかを保証するために mkstemp() を使うべきです。
-<P></P></LI>
-
-<LI>攻撃者が他の任意のシステムへ/からパケットを送る/受け取ることができる
-場合、攻撃者は私たちが受け取るデータを完全に制御できるようになり、
-<B>一切の</B>データは信用できなくなります。
-<P></P></LI>
-
-<LI>設定ファイルが正しい書式で書かれているとか、適切なユーティリティで出
-力されていることを仮定してはいけません。
-ユーザが指定する端末名や言語指定文字列など、パス名に使う可能性のあるものでは、
-'/' や '../../../' などの文字列が含まれる可能性を考慮する必要があります。
-setuid root で動くプログラムの場合には、ユーザにより指定されたパスを
-<B>絶対に</B>信用してはいけません。
-<P></P></LI>
-
-<LI>データが格納される方法にセキュリティホール/弱点がないかどうか
-探してください。
-詮索好きな眼から保護するために、すべての一時ファイルのパーミッション
-は 600 にするべきです。
-<P></P></LI>
-
-<LI>特権で動作するプログラムは、ありきたりの問題を grep するだけ
-ではいけません。
-strcpy() やその類似関数の誤用による、バッファオーバーフローを
-引き起こす方法は数多く存在するので、
-そのようなプログラムではすべての行でオーバーフローの可能性を
-探ってください。
-<P></P></LI>
-
-<LI>ある個所で特権を放棄したからといって、それで exploit が
-なくなるというわけではありません。
-攻撃者は、あとで /bin/sh を実行する際に再び特権が得られるように、
-スタックに必要なコードを置いておくかもしれません。</LI></UL>
-<P></P></LI>
-
-<LI>uid で管理しましょう。
-できる限り早く特権を放棄しましょう(しかも完全に)。
-euid と uid を入れ替えるだけでは十分ではありません。
-可能なら setuid() を使いましょう。
-<P></P></LI>
-
-<LI>エラーが発生しても設定ファイルを表示しないようにします。
-行番号と行内での位置が分かれば十分です。
-これはすべてのライブラリ、suid/sgid プログラムに当てはまります。
-<P></P></LI>
-
-<LI>既存のコードのセキュリティ上の問題を発見するために、
-コードを見直すときには以下の点に注意します:<P></P><UL>
-
-<LI>自分のセキュリティ上の修正に自信がない場合には、
-あらかじめ同意を得ているレビュアーに送って、あなたのコードを
-見直してもらってください。
-セキュリティ上の修正と銘打って何かを壊してしまうと、
-とても恥ずかしい思いをすることになりますので、
-良く理解していないコードを commit しないでください。
-<P></P></LI>
-
-<LI>あなたが commit 権限を持っていない場合、
-権限を持ったレビュアーは、その変更をチェックする最後の人間となります。
-その人がチェックと、最終バージョンをソースツリーに取り入れる作業の
-両方を行うことになります。
-<P></P></LI>
-
-<LI>レビュー用に変更点を送る際には、context diff もしくは unified diff 
-を用いるようにします。
-この diff は patch(1) に簡単に適用できます。
-単純にファイル全体を送るようなことはしないでください。
-diff の出力は読みやすく、
-(複数の変更が同時に加えられたような場合でも)
-手元のソースに簡単に適用できます。
-すべての変更は -current ブランチに対して行うようにします。
-<P></P></LI>
-
-<LI>レビュアーに変更点を送付する前に、必ず自分でその変更をテストするよう
-にします(関連するソースをビルドして実行する、など)。
-明らかに壊れているものをレビューしたがる人はいません。
-そのようなものは提出者が自分が何をしたかをよく確認していない、
-ということをはっきりさせるにすぎません。
-(そんなことでは信頼を得られませんね)。
-もし特定のバージョンのものが入っているマシンのアカウントが必要なら、
-そう尋ねてください。
-プロジェクトはそのような目的のためのリソースを用意しています。
-<P></P></LI>
-
-<LI>コミッターへの注意: -current へのパッチを -stable ブランチに
-適切に適用することを忘れないでください。
-<P></P></LI>
-
-<LI>あなたのスタイルに合うようにコードを書き直す必要はありません。
-そんなことはレビュアーの仕事をより困難にするだけです。
-明白な理由がない限りそのようなことはしないでください。</LI></UL>
-<P></P></LI>
-
-<LI>シグナルハンドラの内部で複雑なことをしているプログラムを
-探してください。
-ライブラリ内の多くのコードは、このようなことを安全に行えるほど
-再入可能ではありません。
-<P></P></LI>
-
-<LI>realloc() の使い方には特別な注意を払ってください。
-多くの場合、この関数は正しく使われていません。
-<P></P></LI>
-
-<LI>固定サイズのバッファを使うときには、バッファのサイズが変わっても
-コードの部分が変更されないということが無いように、sizeof() を
-使うようにしてください。 たとえば:
-<pre>
-        char buf[1024];
-        struct foo { ...};
-        ...
-BAD:
-        xxx(buf, 1024)
-        xxx(yyy, sizeof(struct foo))
-GOOD:
-        xxx(buf, sizeof(buf))
-        xxx(yyy, sizeof(yyy))
-</pre>
-ポインタが指しているもののサイズを知りたいときに、
-ポインタの sizeof をとったりしないよう注意してください。
-<P></P></LI>
-
-<LI>"char foo[###]" のようなものを見たときには、
-すべての foo の使い方が正しいかどうかを調べて、
-オーバーフローする可能性がないかどうかをチェックしてください。
-オーバーフローが避けられない場合には、
-すくなくともバッファを malloc して、スタック上を動き回ることが
-できないようにしてください。
-<P></P></LI>
-
-<LI>ファイル識別子はできる限り早く close してください。
-ライブラリルーチンでは、ファイル識別子は常に “使ったら close”
-するようにしてください。
-<P></P></LI>
-</UL>
-
-<P>有用なツールとして its4 の ports が /usr/ports/security/its4/ に
-あります。 これは自動化された C のコードの検査ツールで、コード中で
-潜在的な問題点をハイライト表示します。 これは最初のチェックには
-便利ですが盲信して頼りすぎてはいけません。 完全な監査は
-コード全体を人の目で確かめることが必要です。</P>
-
-<P>確実なプログラミングテクニックとリソースに関する更なる情報は、
-リソースセンターの
-<A HREF="http://www.shmoo.com/securecode/">How to Write Secure Code</A>
-を見てください。</P>
-
-<A NAME=tat></A>
-<H2>FreeBSD セキュリティ Tips and Tricks</H2>
-<P>FreeBSD システム (実際にはどの &unix; システムでも) を
-セキュアにするにはいくつかのステップがあります:</P>
-<UL>
-
-<LI>潜在的に危険なソフトウェアを無効にする<BR><P></P>
-多くのソフトウェアは特定のリソースを使うために、
-set-uid として実行可能にすることによって
-特権ユーザとして実行されなければなりません。
-たとえば UUCP や PPP はシリアルポートを使うために、
-sendmail はメールスプールに書き込むために、
-bind は特権ポートを使うために、特権ユーザとして実行されます。
-UUCP を使わない場合には、
-システムにソフトウェアがあっても役にたちません。
-また、無効にしている方が得策といえます。
-もちろん、これを行うには、将来的にその機能が必要かの見極めと、
-必要なものと不要なものを分別する知識が必要です。<BR><P></P> 
-swapinfo のように、セキュリティ上の危険性を高める可能性はあるが、
-それほど有用ではないユーティリティに気がつくかと思います。
-('chmod ug-s ファイル名' コマンドを使い)
-プログラムの set-uid ビットを外しても、root の時は swapinfo を常に
-使い続けることができます。
-しかし、多くの s ビットを外すために、常時 root になっている、という
-ことはあまりよいことではありません。
-不要なプログラムを削除するだけではなく、提供しないサービスも
-取り除きます。
-<TT>/etc/inetd.conf</TT> や <TT>/etc/rc.conf</TT> ファイルを編集し、
-不要なサービスをすべて停止することで取り除くことができます。<P></P></LI>
-
-<LI>セキュリティ上のバグがあるソフトウェアを修正するには
-(または、クラッカーの一歩先を行くには)<BR><P></P> 
-まずは、様々な <A HREF="#ml">FreeBSD Security メーリングリスト</A>
-を購読して下さい。バグの最新情報や修正を入手することができます。
-修正は、すぐに当てるようにして下さい。<P></P></LI>
-
-<LI>バックアップ - セキュリティ侵害が起こった場合は、
-システムを修復して下さい。<BR><P></P> 
-常時バックアップを取り、書き換えられていないことが確実な OS
-(例として、CD-Rom) を準備しておきましょう。
-攻撃者によって変造されたり書き換えられたデータがバックアップに
-含まないようにしてください。<P></P></LI>
-
-<LI>システムの状態を監視するソフトウェアのインストール<BR><P></P> 
-(packages や ports にある) tcp wrappers や tripwire のようなプログラムを
-用いて、システムを監視することができます。
-このようなプログラムは、
-侵入者を検知するのに役立ちます。また、毎日 root アカウントへ送られて
-くる /etc/security スクリプトの出力に目を通すようにして下さい。<P></P></LI>
-
-<LI>システムに携わる人の育成<BR><P></P> 
-ユーザーは、自分が何をしているのか
-を理解しなくてはいけません。
-自分のパスワードを他人に渡したり、簡単に推測できるパスワード
-の使用を避けることを教えます。システム/ネットワークの
-セキュリティは、ユーザー自身の手の中にあることを理解すれば
-いいのです。<P></P></LI>
-</UL> 
-
-<P>システムのセキュリティを強化する方法の tips の応用編に
-ついては、以下の FreeBSD Security How-To サイトをご利用下さい。
-<A HREF="http://www.FreeBSD.org/~jkb/howto.html"> 
-http://www.FreeBSD.org/~jkb/howto.html</A></P> 
-<P>セキュリティとは、継続です。
-セキュリティに関する、最新の開発状況を常に把握するようにしてください。</P>
-
-<A NAME=misc></A>
-<H2>セキュリティ上の問題を見つけてしまった時にすべきこと:</H2>
-
-<UL>
-<LI><B>セキュリティ侵害のレベルを決める</B><BR>
-攻撃者はどのような特権を得たのか? root 特権を得たのか、それともユー
-ザーレベルのアクセス権を得ただけなのか?
-</LI>
-
-<LI><B>システム (カーネルや userland) の状態が変更されていないか判断する
-</B><BR>
-どのソフトウェアが変更されたのか? 新しいカーネルはインストール
-されたのか? (telnetd、login のような) システムバイナリは編集されたのか? 
-OS にたいして変更された疑いがある場合は、安全なメディアから OS の
-再インストールを行います。</LI>
-
-<LI><B>不正侵入の手口を見つける</B><BR>
-よく知られているセキュリティバグを通じて侵入はなされたのか? 
-そうであれば、正しいパッチを当てて下さい。
-設定ミスによって侵入がなされたのか?
-侵入は新しいバグによるものなのか? 
-もしそれが新しいバグによるものと思われる場合、
-<A HREF="mailto:security-officer@FreeBSD.org">
-FreeBSD Security Officer</A> までご連絡ください。</LI>
-
-<LI><B>セキュリティホールを修正する</B><BR>
-問題を解決するために、新しいソフトウェアをインストールするか、
-古いソフトウェアにパッチを当てます。危険にさらされたアカウント全てを
-無効にします。</LI>
-
-<LI><B>その他の情報源</B><BR>
-<A HREF="http://www.cert.org">CERT</A>にも、
-システムに侵入された際に取るべき手順について
-<A HREF="http://www.cert.org/nav/recovering.html">詳細</A>が
-載っています。</LI>
-</UL>
-
-<H2>その他の関連するセキュリティ情報</H2>
-<UL>
-<LI><A href="http://www.cerias.purdue.edu/coast/archive/index.html">
-The COAST archive</A>には、セキュリティに関する豊富なコレクション
-があります。</LI>
-
-<LI><A href="http://www.cerias.purdue.edu/infosec/hotlist/">CERIAS
-(Center for Education and Research in Information Assurance and Security)</A>
-は、セキュリティ情報を探す際に最初に目を通すとよいでしょう。
-役立つセキュリティリンクが多数あります。
-あなたがセキュリティについて知りたいと思っていることすべてが
-……いや、それ以上のことが載っています。</LI>
-
-<LI><A href="http://www.cert.org">http://www.cert.org</A>や
-<A href="http://www.auscert.org.au">http://www.auscert.org.au</A>
-のような様々なCERTチーム</LI>
-
-<LI><A HREF="http://www.geek-girl.com/bugtraq/">Bugtraq</A>や
-<A HREF="http://list.nfr.com/forum/firewall-wizards.html">
-Firewall Wizards</A>のようなメーリングリスト</LI>
-</UL>
-
-	&footer;
-    </body>
+    &footer;
+  </body>
 </html>