<?xml version="1.0" encoding="euc-jp"?>
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
"http://www.FreeBSD.org/XML/doc/share/xml/xhtml10-freebsd.dtd" [
<!ENTITY title "FreeBSD セキュリティ脆弱性の報告に関する情報">
]>
<!-- $FreeBSD$ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: r42226 -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>&title;</title>
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
</head>
<body class="navinclude.support">
<h2>目次</h2>
<ul>
<li><a href="#how">FreeBSD セキュリティ問題の報告方法と連絡先について</a></li>
<li><a href="#sec">FreeBSD セキュリティオフィサについて</a></li>
<li><a href="#pol">情報の取り扱いに関する方針</a></li>
<li><a href="security.html#sup">サポートされている FreeBSD のリリース</a></li>
<li><a href="unsupported.html">サポートが終了した FreeBSD リリース</a></li>
</ul>
<a name="how"></a>
<h2>FreeBSD セキュリティ問題の報告方法と連絡先について</h2>
<p>FreeBSD に関わるすべてのセキュリティ問題は、
<a href="mailto:secteam@FreeBSD.org">FreeBSD セキュリティチーム</a>
に (英語で) 報告してください。高い機密性が要求される場合には、
<a href="&enbase;/security/so_public_key.asc">セキュリティオフィサの PGP 鍵</a>
を使って暗号化し、
<a href="mailto:security-officer@FreeBSD.org">セキュリティオフィサチーム</a>
へ (英語で) 報告してください。
報告には少なくとも以下を含める必要があります。</p>
<ul>
<li>脆弱性の詳細</li>
<li>可能であれば影響範囲 (FreeBSD のどのバージョンに影響するか)</li>
<li>何らかの回避方法</li>
<li>可能であればコードの例</li>
</ul>
<p>問題の報告後、
セキュリティオフィサまたはセキュリティチーム代表からの返信があります。</p>
<h3>スパムフィルタ</h3>
<p>セキュリティに関する連絡先のメインのメールアドレスには、
大量のスパムメールが送られてくるので、スパムフィルタが導入されています。
もし、FreeBSD
セキュリティオフィサやセキュリティチームと連絡がつかない場合には、
スパムフィルタが原因と考えられます。
通常のアドレスの代わりに、
<tt>security-officer-<em>XXXX</em>@FreeBSD.org</tt>
の <em>XXXX</em> を <tt>3432</tt> に置き換えたアドレスにメールを送ってください。
このアドレスは、定期的に変わる可能性があるので、
このページで最新のアドレスを確認してください。
このアドレスへのメールは、FreeBSD セキュリティオフィサチームに届きます。</p>
<a name="sec"></a>
<h2>FreeBSD セキュリティオフィサチームと FreeBSD セキュリティチーム</h2>
<p>FreeBSD プロジェクトでは、脆弱性の報告に対して臨機応変に対応する目的で
セキュリティオフィサのメールエイリアスに 3 人
(セキュリティオフィサ、セキュリティオフィサ補佐、
コアチームメンバ 1 人) が登録されています。つまり、<a
href="mailto:security-officer@FreeBSD.org"><security-officer@FreeBSD.org></a>
へ送られたメールは、現在以下のメールアドレスへ届くようになっています。</p>
<table>
<tr valign="top">
<td>&a.des.email;</td>
<td>セキュリティオフィサ</td>
</tr>
<tr valign="top">
<td>&a.delphij.email;</td>
<td>セキュリティオフィサ補佐</td>
</tr>
<tr valign="top">
<td>&a.simon.email;</td>
<td>名誉セキュリティオフィサ</td>
</tr>
<tr valign="top">
<td>&a.cperciva.email;</td>
<td>名誉セキュリティオフィサ</td>
</tr>
<tr valign="top">
<td>&a.rwatson.email;</td>
<td>リリースエンジニアリング渉外、<br/>
TrustedBSD プロジェクト渉外、システムセキュリティアーキテクチャの専門家</td>
</tr>
</table>
<p>また、セキュリティオフィサが選出したコミッターグループである
<a href="&enbase;/administration.html#t-secteam" >FreeBSD
セキュリティチーム</a> <a
href="mailto:secteam@FreeBSD.org"><secteam@FreeBSD.org></a> が、
セキュリティオフィサをサポートしています。</p>
<a name="pol"></a>
<h2>情報の取り扱いに関する方針</h2>
<p>セキュリティオフィサは一般的な方針として、
脆弱性の発見から、その危険性の解析と修正、修正のテスト、
関係する他の組織との調整などに必要と思われる時間が経過した後に、
その問題に関するすべての情報を公開することを原則とします。</p>
<p>セキュリティオフィサは、
FreeBSD プロジェクトの資源を脅かすような緊急性の高い脆弱性を
FreeBSD クラスタ管理者の一人ないし複数の人たちに<em>かならず</em>通知します。</p>
<p>セキュリティオフィサは、
問題を完全に理解したり修正するために専門的知識や意見が必要とされる場合、
報告されたセキュリティ上の脆弱性について議論を行なうためにセキュリティオフィサ以外の
FreeBSD の開発者や外部の開発者に協力を求めることがあります。
報告された脆弱性に関する情報には不必要な流出を最小限に抑える努力を行い、また、
議論に参加する専門家はセキュリティオフィサの方針に従います。
過去、議論に参加した専門家たちは、FFS、VM システム、ネットワークスタックなど、
オペレーティングシステムの非常に複雑なコンポーネントについて
豊富な経験を持っていることを理由に選ばれています。</p>
<p>FreeBSD のリリース作業が進行中の場合、
セキュリティオフィサは適切なリリースサイクルや、
予定されているリリースに深刻なセキュリティ上のバグが含まれているかどうかといった情報を判断材料として提供する目的で、
リリースエンジニアに脆弱性の存在やその影響の大きさを知らせることがあります。
ただしそれが必要だと判断された場合には、
脆弱性の存在やその影響に関する情報の不必要な漏洩を防ぐために、
リリースエンジニアに脆弱性の情報を提供しない場合もあります。</p>
<p>FreeBSD セキュリティオフィサは、FreeBSD とコードを共有しているサードパーティベンダ
(OpenBSD, NetBSD および DragonFlyBSD プロジェクト、Apple,
FreeBSD に由来するソフトウェアのベンダ、
Linux ベンダのセキュリティリスト) はもちろんのこと、
他の団体や CERT
(訳注: 日本では <a href="http://www.jpcert.or.jp/">JPCERT/CC</a>)
のような、脆弱性やセキュリティに関する出来事を追跡する組織と
緊密に協調して作業を行っています。
脆弱性は FreeBSD 以外の実装にも影響することがあり、(頻繁ではありませんが)
世界中のネットワークコミュニティに影響する可能性もあります。そのような際、
セキュリティオフィサは脆弱性に関する情報を他の団体へ公開することがあります。
もしそれが不都合な場合は、脆弱性の報告にその旨を明記してください。</p>
<p>あなたが情報を提供する際に、提供する情報に何か特別な扱いが必要ならば、
それを明記するのを忘れないようにお願いします。</p>
<p>脆弱性の報告を行なう際に、
報告者が他のベンダとの間で公開の日程を調整したいと考えている場合は、
脆弱性の報告にその旨を明記してください。明確な指定がない場合、
FreeBSD セキュリティオフィサは、解決策の検証が十分に行なわれ次第、
可能な限り迅速に情報を公開できるような時期を選びます。
ただし、もし脆弱性が (bugtraq のような) 公的なフォーラムで活発に議論されているとか、
すでに積極的に悪用されているといった状態ならば、
セキュリティオフィサはユーザコミュニティの安全を最大限に確保するため、
報告者の指定した公開スケジュールを無視する可能性があることに注意してください。</p>
<p>情報を提供する際は、PGP を使って暗号化しても構いません。
また、その旨を明記すれば、それに対する返信も PGP を用いて暗号化されます。</p>
</body>
</html>