362 lines
14 KiB
Text
362 lines
14 KiB
Text
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
|
|
<!ENTITY base CDATA "..">
|
|
<!ENTITY date "$FreeBSD: www/en/security/security.sgml,v 1.184 2006/05/12 12:30:21 cperciva Exp $">
|
|
<!ENTITY title "FreeBSD Security Information">
|
|
<!ENTITY % navincludes SYSTEM "../includes.navsupport.sgml"> %navincludes;
|
|
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
|
<!ENTITY % developers SYSTEM "../developers.sgml"> %developers;
|
|
<!ENTITY advisories.html.inc SYSTEM "advisories.html.inc">
|
|
]>
|
|
<!-- $FreeBSD: www/en/security/security.sgml,v 1.184 2006/05/12 12:30:21 cperciva Exp $ -->
|
|
|
|
<html>
|
|
&header;
|
|
|
|
<h2>Introduction</h2>
|
|
|
|
<p>This web page is designed to assist both new and experienced
|
|
users in the area of FreeBSD security. FreeBSD takes security
|
|
very seriously and is constantly working on making the OS as
|
|
secure as possible.</p>
|
|
|
|
<p>Here you will find additional information, or links to
|
|
information, on how to protect your system against various types
|
|
of attack, on whom to contact if you find a security-related bug,
|
|
and so on. There is also a section on the various ways that the
|
|
systems programmer can become more security conscious so that he
|
|
is less likely to introduce vulnerabilities.</p>
|
|
|
|
<h2>Table of Contents</h2>
|
|
|
|
<ul>
|
|
<li><a href="#how">How and Where to report a FreeBSD security issue</a></li>
|
|
<li><a href="#sec">Information about the FreeBSD Security Officer</a></li>
|
|
<li><a href="charter.html">Charter for the Security Officer and Team</a></li>
|
|
<li><a href="#pol">Information handling policies</a></li>
|
|
<li><a href="#adv">FreeBSD Security Advisories</a></li>
|
|
<li><a href="&base;/doc/en_US.ISO8859-1/books/handbook/security-advisories.html">
|
|
Reading FreeBSD Security Advisories</a></li>
|
|
</ul>
|
|
|
|
<a name="how"></a>
|
|
<p>All FreeBSD Security issues should be reported to the <a
|
|
href="mailto:secteam@FreeBSD.org">FreeBSD Security Team</a>
|
|
or, if a higher level of confidentiality is required, to the <a
|
|
href="mailto:security-officer@FreeBSD.org">Security Officer Team</a>.
|
|
All reports should at least contain:</p>
|
|
|
|
<ul>
|
|
<li>A description of the vulnerability.</li>
|
|
<li>What versions of FreeBSD seem to be affected if possible.</li>
|
|
<li>Any plausible workaround.</li>
|
|
<li>Example code if possible.</li>
|
|
</ul>
|
|
|
|
<p>After this information has been reported the Security Officer or
|
|
a Security Team delegate will get back with you.</p>
|
|
|
|
<a name=sec></a>
|
|
<h2>The FreeBSD Security Officer and the Security Officer Team</h2>
|
|
|
|
<p>To better coordinate information exchange with others in the
|
|
security community, FreeBSD has a focal point for security-related
|
|
communications: the FreeBSD Security Officer.</p>
|
|
|
|
<p>If you need to contact the FreeBSD Project about a possible
|
|
security issue, you should therefore <a
|
|
href="mailto:security-officer@FreeBSD.org">send mail to the
|
|
Security Officer</a> with a description of what you have found and
|
|
the type of vulnerability it represents.</p>
|
|
|
|
<p>In order that the FreeBSD Project may respond to vulnerability
|
|
reports in a timely manner, there are four members of the Security
|
|
Officer mail alias: the Security Officer, Security Officer
|
|
Emeritus, Deputy Security Officer, and one Core Team member.
|
|
Therefore, messages sent to the <a
|
|
href="mailto:security-officer@FreeBSD.org"><security-officer@FreeBSD.org></a>
|
|
mail alias are currently delivered to:</p>
|
|
|
|
<table>
|
|
<tr valign="top">
|
|
<td>&a.cperciva; <a
|
|
href="mailto:cperciva@FreeBSD.org"><cperciva@FreeBSD.org></a></td>
|
|
<td>Security Officer</td>
|
|
</tr>
|
|
<tr valign="top">
|
|
<td>&a.nectar; <a
|
|
href="mailto:nectar@FreeBSD.org"><nectar@FreeBSD.org></a></td>
|
|
<td>Security Officer Emeritus</td>
|
|
</tr>
|
|
<tr valign="top">
|
|
<td>&a.simon; <a
|
|
href="mailto:simon@FreeBSD.org"><simon@FreeBSD.org></a></td>
|
|
<td>Deputy Security Officer</td>
|
|
</tr>
|
|
<tr valign="top">
|
|
<td>&a.rwatson; <a
|
|
href="mailto:rwatson@FreeBSD.org"><rwatson@FreeBSD.org></a></td>
|
|
<td>FreeBSD Core Team liaison, Release Engineering liaison,<br>
|
|
TrustedBSD Project liaison, system security architecture expert</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>The Security Officer is supported by the <a
|
|
href="&base;/doc/en_US.ISO8859-1/articles/contributors/staff-listing.html#STAFF-SECTEAM"
|
|
>FreeBSD Security Team</a> <a
|
|
href="mailto:secteam@FreeBSD.org"><secteam@FreeBSD.org></a>,
|
|
a small group of committers
|
|
vetted by the Security Officer.</p>
|
|
|
|
<p>Please use the <a
|
|
href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/public_key.asc">Security
|
|
Officer PGP key</a> to encrypt your messages to the Security
|
|
Officer when appropriate.</p>
|
|
|
|
<a name="pol"></a>
|
|
<h2>Information handling policies</h2>
|
|
|
|
<p>As a general policy, the FreeBSD Security Officer favors full
|
|
disclosure of vulnerability information after a reasonable delay
|
|
to permit safe analysis and correction of a vulnerability, as well
|
|
as appropriate testing of the correction, and appropriate
|
|
coordination with other affected parties.</p>
|
|
|
|
<p>The Security Officer <em>will</em> notify one or more of the <a
|
|
href="mailto:admins@FreeBSD.org">FreeBSD Cluster Admins</a> of
|
|
vulnerabilities that put the FreeBSD Project's resources under
|
|
immediate danger.</p>
|
|
|
|
<p>The Security Officer may bring additional FreeBSD developers or
|
|
outside developers into discussion of a submitted security
|
|
vulnerability if their expertise is required to fully understand
|
|
or correct the problem. Appropriate discretion will be exercised
|
|
to minimize unnecessary distribution of information about the
|
|
submitted vulnerability, and any experts brought in will act in
|
|
accordance of Security Officer policies. In the past, experts
|
|
have been brought in based on extensive experience with highly
|
|
complex components of the operating system, including FFS, the VM
|
|
system, and the network stack.</p>
|
|
|
|
<p>If a FreeBSD release process is underway, the FreeBSD Release
|
|
Engineer may also be notified that a vulnerability exists, and its
|
|
severity, so that informed decisions may be made regarding the
|
|
release cycle and any serious security bugs present in software
|
|
associated with an up-coming release. If requested, the Security
|
|
Officer will not share information regarding the nature of the
|
|
vulnerability with the Release Engineer, limiting information flow
|
|
to existence and severity.</p>
|
|
|
|
<p>The FreeBSD Security Officer has close working relationships with
|
|
a number of other organizations, including third-party vendors
|
|
that share code with FreeBSD (the OpenBSD, NetBSD and DragonFlyBSD
|
|
projects, Apple, and other vendors deriving software from FreeBSD,
|
|
as well as the Linux vendor security list), as well as
|
|
organizations that track vulnerabilities and security incidents,
|
|
such as CERT. Frequently vulnerabilities may extend beyond the
|
|
scope of the FreeBSD implementation, and (perhaps less frequently)
|
|
may have broad implications for the global networking community.
|
|
Under such circumstances, the Security Officer may wish to
|
|
disclose vulnerability information to these other organizations:
|
|
if you do not wish the Security Officer to do this, please
|
|
indicate so explicitly in any submissions.</p>
|
|
|
|
<p>Submitters should be careful to explicitly document any special
|
|
information handling requirements.</p>
|
|
|
|
<p>If the submitter of a vulnerability is interested in a
|
|
coordinated disclosure process with the submitter and/or other
|
|
vendors, this should be indicated explicitly in any submissions.
|
|
In the absence of explicit requests, the FreeBSD Security Officer
|
|
will select a disclosure schedule that reflects both a desire for
|
|
timely disclosure and appropriate testing of any solutions.
|
|
Submitters should be aware that if the vulnerability is being
|
|
actively discussed in public forums (such as bugtraq), and
|
|
actively exploited, the Security Officer may choose not to follow
|
|
a proposed disclosure timeline in order to provide maximum
|
|
protection for the user community.</p>
|
|
|
|
<p>Submissions may be protected using PGP. If desired, responses
|
|
will also be protected using PGP.</p>
|
|
|
|
<a name=adv></a>
|
|
<h2>FreeBSD Security Advisories</h2>
|
|
|
|
<p>The FreeBSD Security Officer provides security advisories for
|
|
several branches of FreeBSD development. These are the
|
|
<em>-STABLE Branches</em> and the <em>Security Branches</em>.
|
|
(Advisories are not issued for the <em>-CURRENT Branch</em>.)</p>
|
|
|
|
<ul>
|
|
|
|
<li><p>There is usually only a single -STABLE branch, although
|
|
during the transition from one major development line to another
|
|
(such as from FreeBSD 4.x to 5.x), there is a time span in which
|
|
there are two -STABLE branches. The -STABLE branch tags have
|
|
names like <tt>RELENG_4</tt>. The corresponding builds have
|
|
names like <tt>FreeBSD 4.10-STABLE</tt>.</p></li>
|
|
|
|
<li><p>Each FreeBSD Release has an associated Security Branch.
|
|
The Security Branch tags have names like <tt>RELENG_4_10</tt>.
|
|
The corresponding builds have names like <tt>FreeBSD
|
|
4.10-RELEASE-p5</tt>.</p></li>
|
|
</ul>
|
|
|
|
<p>Issues affecting the FreeBSD Ports Collection are covered in <a
|
|
href="http://vuxml.FreeBSD.org/">the FreeBSD VuXML
|
|
document</a>.</p>
|
|
|
|
<p>Each branch is supported by the Security Officer for a limited
|
|
time only, and is designated as one of `<em>Early adopter</em>',
|
|
`<em>Normal</em>', or `<em>Extended</em>'. The designation is
|
|
used as a guideline for determining the lifetime of the branch as
|
|
follows.</p>
|
|
|
|
<dl>
|
|
<dt>Early adopter</dt>
|
|
<dd>Releases which are published from the -CURRENT branch will be
|
|
supported by the Security Officer for a minimum of 6 months after
|
|
the release.</dd>
|
|
<dt>Normal</dt>
|
|
<dd>Releases which are published from the -STABLE branch will be
|
|
supported by the Security Officer for a minimum of 12 months after the
|
|
release.</dd>
|
|
<dt>Extended</dt>
|
|
<dd>Selected releases will be supported by the Security Officer for a
|
|
minimum of 24 months after the release.</dd>
|
|
</dl>
|
|
|
|
<a name="supported-branches"></a>
|
|
|
|
<p>The current designation and estimated lifetimes of the currently
|
|
supported branches are given below. The <em>Estimated EoL
|
|
(end-of-life)</em> column gives the earliest date on which that
|
|
branch is likely to be dropped. Please note that these dates may
|
|
be extended into the future, but only extenuating circumstances
|
|
would lead to a branch's support being dropped earlier than the
|
|
date listed.</p>
|
|
|
|
<!--
|
|
Please also update www/en/releng/index.sgml when updating this
|
|
list of supported branches.
|
|
-->
|
|
<table class="tblbasic">
|
|
<tr>
|
|
<th>Branch</th>
|
|
<th>Release</th>
|
|
<th>Type</th>
|
|
<th>Release Date</th>
|
|
<th>Estimated EoL</th>
|
|
</tr>
|
|
<tr>
|
|
<td>RELENG_4</td>
|
|
<td>n/a</td>
|
|
<td>n/a</td>
|
|
<td>n/a</td>
|
|
<td>January 31, 2007</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RELENG_4_10</td>
|
|
<td>4.10-RELEASE</td>
|
|
<td>Extended</td>
|
|
<td>May 27, 2004</td>
|
|
<td>May 31, 2006</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RELENG_4_11</td>
|
|
<td>4.11-RELEASE</td>
|
|
<td>Extended</td>
|
|
<td>January 25, 2005</td>
|
|
<td>January 31, 2007</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RELENG_5</td>
|
|
<td>n/a</td>
|
|
<td>n/a</td>
|
|
<td>n/a</td>
|
|
<td>May 31, 2008</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RELENG_5_3</td>
|
|
<td>5.3-RELEASE</td>
|
|
<td>Extended</td>
|
|
<td>November 6, 2004</td>
|
|
<td>October 31, 2006</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RELENG_5_4</td>
|
|
<td>5.4-RELEASE</td>
|
|
<td>Normal</td>
|
|
<td>May 9, 2005</td>
|
|
<td>October 31, 2006</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RELENG_5_5</td>
|
|
<td>5.5-RELEASE</td>
|
|
<td>Extended</td>
|
|
<td>May 25, 2006</td>
|
|
<td>May 31, 2008</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RELENG_6</td>
|
|
<td>n/a</td>
|
|
<td>n/a</td>
|
|
<td>n/a</td>
|
|
<td>May 31, 2008</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RELENG_6_0</td>
|
|
<td>6.0-RELEASE</td>
|
|
<td>Normal</td>
|
|
<td>November 4, 2005</td>
|
|
<td>November 30, 2006</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RELENG_6_1</td>
|
|
<td>6.1-RELEASE</td>
|
|
<td>Extended</td>
|
|
<td>May 9, 2006</td>
|
|
<td>May 31, 2008</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>Older releases are not maintained and users are strongly
|
|
encouraged to upgrade to one of the supported releases mentioned
|
|
above.</p>
|
|
|
|
<p>Some statistics about advisories released during 2002:</p>
|
|
|
|
<ul>
|
|
<li>44 advisories of varying severity were issued for the base
|
|
system.</li>
|
|
<li>12 advisories described vulnerabilities found only in FreeBSD.
|
|
The remaining 32 were problems shared with at least one other OS
|
|
(often due to shared code).</li>
|
|
|
|
<li>6 security notices were issued, covering a total of 95 issues
|
|
in optional third party applications included in the Ports
|
|
Collection.</li>
|
|
</ul>
|
|
|
|
<p>Advisories are sent to the following FreeBSD mailing lists:</p>
|
|
<ul>
|
|
<li>FreeBSD-security-notifications@FreeBSD.org</li>
|
|
<li>FreeBSD-security@FreeBSD.org</li>
|
|
<li>FreeBSD-announce@FreeBSD.org</li>
|
|
</ul>
|
|
|
|
<p>Advisories are always signed using the FreeBSD Security Officer
|
|
<a href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/public_key.asc">PGP
|
|
key</a> and are archived, along with their associated
|
|
patches, at our <a
|
|
href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/index.html">FTP CERT
|
|
repository</a>. At the time of this writing, the following
|
|
advisories are currently available (note that this list may be a
|
|
few days out of date - for the very latest advisories please check
|
|
the <a href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/">FTP
|
|
site</a>):</p>
|
|
|
|
&advisories.html.inc;
|
|
|
|
&footer;
|
|
</body>
|
|
</html>
|