be supported by the FreeBSD Security Team. Due to slippage in the FreeBSD 6.2 release schedule, the FreeBSD 6.0 EoL is being pushed back two months to the end of January 2007, in order to allow time for users to upgrade once FreeBSD 6.2 is released.
340 lines
13 KiB
Text
340 lines
13 KiB
Text
<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
|
|
<!ENTITY base CDATA "..">
|
|
<!ENTITY date "$FreeBSD: www/en/security/security.sgml,v 1.190 2006/08/19 21:20:52 hrs Exp $">
|
|
<!ENTITY title "FreeBSD Security Information">
|
|
<!ENTITY % navinclude.support "INCLUDE">
|
|
<!ENTITY % developers SYSTEM "../developers.sgml"> %developers;
|
|
<!ENTITY advisories.html.inc SYSTEM "advisories.html.inc">
|
|
]>
|
|
<!-- $FreeBSD: www/en/security/security.sgml,v 1.190 2006/08/19 21:20:52 hrs 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
|
|
FreeBSD Cluster Admins 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 5.x to 6.x), there is a time span in which
|
|
there are two -STABLE branches. The -STABLE branch tags have
|
|
names like <tt>RELENG_6</tt>. The corresponding builds have
|
|
names like <tt>FreeBSD 6.1-STABLE</tt>.</p></li>
|
|
|
|
<li><p>Each FreeBSD Release has an associated Security Branch.
|
|
The Security Branch tags have names like <tt>RELENG_6_1</tt>.
|
|
The corresponding builds have names like <tt>FreeBSD
|
|
6.1-RELEASE-p1</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 a -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_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_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>last release + 2 years</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RELENG_6_0</td>
|
|
<td>6.0-RELEASE</td>
|
|
<td>Normal</td>
|
|
<td>November 4, 2005</td>
|
|
<td>January 31, 2007</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>
|