313 lines
12 KiB
Text
313 lines
12 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.162 2004/06/08 08:00:08 des Exp $">
|
||
<!ENTITY title "FreeBSD Security Information">
|
||
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
||
<!ENTITY advisories.html.inc SYSTEM "advisories.html.inc">
|
||
]>
|
||
<!-- $FreeBSD: www/en/security/security.sgml,v 1.162 2004/06/08 08:00:08 des 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="http://www.freebsd.org/handbook/security-advisories.html">
|
||
Reading FreeBSD Security Advisories</a></li>
|
||
</UL>
|
||
|
||
<a name="how"></a>
|
||
<p>All FreeBSD Security issues should be reported directly to the
|
||
<a href="mailto:security@FreeBSD.org">Security Officer Team</a>
|
||
personally or otherwise to the <a href="mailto:security-officer@FreeBSD.org">
|
||
Security Officer</a>. All reports should at least contain:<br><br>
|
||
A description of the vulnerability;<br>
|
||
What versions of FreeBSD seem to be affected if possible;<br>
|
||
Any plausible workaround;<br>
|
||
And example code if possible.<br></p>
|
||
|
||
<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, the Deputy Security Officer,
|
||
and two Core Team members. 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>Jacques Vidrine <a
|
||
href="mailto:nectar@FreeBSD.org"><nectar@FreeBSD.org></a></td>
|
||
<td>Security Officer</td>
|
||
</tr>
|
||
<tr valign="top">
|
||
<td>Dag-Erling Sm<53>rgrav <a
|
||
href="mailto:des@FreeBSD.org"><des@FreeBSD.org></a></td>
|
||
<td>Deputy Security Officer</td>
|
||
</tr>
|
||
<tr valign="top">
|
||
<td>Robert Watson <a
|
||
href="mailto:rwatson@FreeBSD.org"><rwatson@FreeBSD.org></a></td>
|
||
<td>FreeBSD Core Team member, Release Engineering liaison,<br>
|
||
TrustedBSD Project liaison, system security architecture expert</td>
|
||
</tr>
|
||
<tr valign="top">
|
||
<td>Warner Losh <a
|
||
href="mailto:imp@FreeBSD.org"><imp@FreeBSD.org></a></td>
|
||
<td>FreeBSD Core Team liaison, Security Officer Emeritus</td>
|
||
</tr>
|
||
</table>
|
||
|
||
<p>The Security Officer is supported by the <a
|
||
href="mailto:security@FreeBSD.org">FreeBSD Security Team
|
||
<security@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 and NetBSD 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>Submitters should be aware that the FreeBSD Project is an open
|
||
source project, and source revision control information for every
|
||
change made to the FreeBSD source tree is publicly accessible. If a
|
||
disclosure schedule is provided, it should take into account both the
|
||
official release of advisory, patch, and update information, as well
|
||
as initial inclusion of fixes in the FreeBSD source tree. There is
|
||
necessarily a lag between the inclusion of fixes in the tree and the
|
||
generation and releases of advisories, patches, and binary updates, as
|
||
the source control system is used to generate them.</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.6-STABLE</TT>.</P></LI>
|
||
|
||
<LI><P>Each FreeBSD Release has an associated Security Branch.
|
||
The Security Branch tags have names like <TT>RELENG_4_6</TT>.
|
||
The corresponding builds have names like <TT>FreeBSD
|
||
4.6-RELEASE-p7</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>
|
||
|
||
<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>
|
||
|
||
<TABLE BORDER="3" CELLSPACING="0" CELLPADDING="2">
|
||
<TR>
|
||
<TH>Branch</TH>
|
||
<TH>Release</TH>
|
||
<TH>Type</TH>
|
||
<TH>Estimated EoL</TH>
|
||
</TR>
|
||
<TR>
|
||
<TD>RELENG_4</TD>
|
||
<TD>n/a</TD>
|
||
<TD>n/a</TD>
|
||
<TD>March 31, 2005</TD>
|
||
</TR>
|
||
<TR>
|
||
<TD>RELENG_4_8</TD>
|
||
<TD>4.8-RELEASE</TD>
|
||
<TD>Extended</TD>
|
||
<TD>March 31, 2005</TD>
|
||
</TR>
|
||
<TR>
|
||
<TD>RELENG_5_2</TD>
|
||
<TD>5.2.1-RELEASE</TD>
|
||
<TD>Early adopter</TD>
|
||
<TD>December 31, 2004</TD>
|
||
</TR>
|
||
<TR>
|
||
<TD>RELENG_4_9</TD>
|
||
<TD>4.9-RELEASE</TD>
|
||
<TD>Normal</TD>
|
||
<TD>October 31, 2004</TD>
|
||
</TR>
|
||
<TR>
|
||
<TD>RELENG_4_10</TD>
|
||
<TD>4.10-RELEASE</TD>
|
||
<TD>Extended</TD>
|
||
<TD>May 31, 2006</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>Like all development efforts, security fixes are first brought into
|
||
the <A HREF="../doc/en_US.ISO8859-1/books/handbook/cutting-edge.html#CURRENT">FreeBSD-current</A> branch.
|
||
After a couple of days and some testing, the fix is retrofitted into
|
||
the supported FreeBSD-stable branch(es) and an advisory is then sent
|
||
out.</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>
|