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.
- -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.
- -All FreeBSD Security issues should be reported directly to the
-Security Officer Team
-personally or otherwise to the
-Security Officer. All reports should at least contain:
-A description of the vulnerability;
-What versions of FreeBSD seem to be affected if possible;
-Any plausible workaround;
-And example code if possible.
After this information has been reported the Security Officer -or a Security Team delegate will get back with you.
- - -To better coordinate information exchange with others in the security -community, FreeBSD has a focal point for security-related communications: -the FreeBSD Security Officer.
- -If you need to contact the FreeBSD Project about -a possible security issue, you should therefore send mail to the Security -Officer with a description of what you have found and the type of -vulnerability it represents.
- -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 -<security-officer@FreeBSD.org> -mail alias are currently delivered to:
- -| &a.cperciva; <cperciva@FreeBSD.org> | -Security Officer | -
| &a.nectar; <nectar@FreeBSD.org> | -Security Officer Emeritus | -
| &a.simon; <simon@FreeBSD.org> | -Deputy Security Officer | -
| &a.rwatson; <rwatson@FreeBSD.org> | -FreeBSD Core Team liaison, Release Engineering liaison, - TrustedBSD Project liaison, system security architecture expert |
-
The Security Officer is supported by the FreeBSD Security Team -<security@FreeBSD.org>, a small group of committers -vetted by the Security Officer.
- -Please use the Security -Officer PGP key to encrypt your messages to the Security Officer -when appropriate.
- - -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.
- -The Security Officer will notify one or more of the -FreeBSD Cluster Admins of -vulnerabilities that put the FreeBSD Project's resources under -immediate danger.
- -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.
- -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.
- -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.
- -Submitters should be careful to explicitly document any special -information handling requirements.
- -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.
- -Submissions may be protected using PGP. If desired, responses will -also be protected using PGP.
- - -The FreeBSD Security Officer provides security advisories for -several branches of FreeBSD development. These are the -STABLE -Branches and the Security Branches. (Advisories are not -issued for the -CURRENT Branch.)
- -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 RELENG_4. The corresponding builds have names like -FreeBSD 4.10-STABLE.
Each FreeBSD Release has an associated Security Branch. -The Security Branch tags have names like RELENG_4_10. -The corresponding builds have names like FreeBSD -4.10-RELEASE-p5.
Issues affecting the FreeBSD Ports Collection are covered -in the FreeBSD VuXML -document.
- -Each branch is supported by the Security Officer for a limited time -only, and is designated as one of `Early adopter', -`Normal', or `Extended'. The designation is used as a -guideline for determining the lifetime of the branch as follows.
- -The current designation and estimated lifetimes of the currently -supported branches are given below. The Estimated EoL -(end-of-life) 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.
- - -| Branch | -Release | -Type | -Release Date | -Estimated EoL | -
|---|---|---|---|---|
| RELENG_4 | -n/a | -n/a | -n/a | -January 31, 2007 | -
| RELENG_4_10 | -4.10-RELEASE | -Extended | -May 27, 2004 | -May 31, 2006 | -
| RELENG_4_11 | -4.11-RELEASE | -Extended | -January 25, 2005 | -January 31, 2007 | -
| RELENG_5 | -n/a | -n/a | -n/a | -May 31, 2007 | -
| RELENG_5_3 | -5.3-RELEASE | -Extended | -November 6, 2004 | -October 31, 2006 | -
| RELENG_5_4 | -5.4-RELEASE | -Normal | -May 9, 2005 | -May 31, 2006 | -
Older releases are not maintained and users are strongly encouraged -to upgrade to one of the supported releases mentioned above.
- -Some statistics about advisories released during 2002:
-Advisories are sent to the following FreeBSD mailing lists:
-Advisories are always signed using the FreeBSD Security Officer - PGP key - and are archived, along with their associated patches, at our -FTP CERT -repository. 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 -FTP site):
- -&advisories.html.inc; - - &footer; - + &header; + +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.
+ +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.
+ +All FreeBSD Security issues should be reported directly to the Security Officer Team
+ personally or otherwise to the Security Officer.
+ All reports should at least contain:
A description of the
+ vulnerability;
What versions of FreeBSD seem to be affected if
+ possible;
Any plausible workaround;
And example code if
+ possible.
After this information has been reported the Security Officer or + a Security Team delegate will get back with you.
+ + +To better coordinate information exchange with others in the + security community, FreeBSD has a focal point for security-related + communications: the FreeBSD Security Officer.
+ +If you need to contact the FreeBSD Project about a possible + security issue, you should therefore send mail to the + Security Officer with a description of what you have found and + the type of vulnerability it represents.
+ +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 <security-officer@FreeBSD.org> + mail alias are currently delivered to:
+ +| &a.cperciva; <cperciva@FreeBSD.org> | +Security Officer | +
| &a.nectar; <nectar@FreeBSD.org> | +Security Officer Emeritus | +
| &a.simon; <simon@FreeBSD.org> | +Deputy Security Officer | +
| &a.rwatson; <rwatson@FreeBSD.org> | +FreeBSD Core Team liaison, Release Engineering liaison, + TrustedBSD Project liaison, system security architecture expert |
+
The Security Officer is supported by the FreeBSD Security Team + <security@FreeBSD.org>, a small group of committers + vetted by the Security Officer.
+ +Please use the Security + Officer PGP key to encrypt your messages to the Security + Officer when appropriate.
+ + +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.
+ +The Security Officer will notify one or more of the FreeBSD Cluster Admins of + vulnerabilities that put the FreeBSD Project's resources under + immediate danger.
+ +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.
+ +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.
+ +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.
+ +Submitters should be careful to explicitly document any special + information handling requirements.
+ +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.
+ +Submissions may be protected using PGP. If desired, responses + will also be protected using PGP.
+ + +The FreeBSD Security Officer provides security advisories for + several branches of FreeBSD development. These are the + -STABLE Branches and the Security Branches. + (Advisories are not issued for the -CURRENT Branch.)
+ +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 RELENG_4. The corresponding builds have + names like FreeBSD 4.10-STABLE.
Each FreeBSD Release has an associated Security Branch. + The Security Branch tags have names like RELENG_4_10. + The corresponding builds have names like FreeBSD + 4.10-RELEASE-p5.
Issues affecting the FreeBSD Ports Collection are covered in the FreeBSD VuXML + document.
+ +Each branch is supported by the Security Officer for a limited + time only, and is designated as one of `Early adopter', + `Normal', or `Extended'. The designation is + used as a guideline for determining the lifetime of the branch as + follows.
+ +The current designation and estimated lifetimes of the currently + supported branches are given below. The Estimated EoL + (end-of-life) 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.
+ + +| Branch | +Release | +Type | +Release Date | +Estimated EoL | +
|---|---|---|---|---|
| RELENG_4 | +n/a | +n/a | +n/a | +January 31, 2007 | +
| RELENG_4_10 | +4.10-RELEASE | +Extended | +May 27, 2004 | +May 31, 2006 | +
| RELENG_4_11 | +4.11-RELEASE | +Extended | +January 25, 2005 | +January 31, 2007 | +
| RELENG_5 | +n/a | +n/a | +n/a | +May 31, 2007 | +
| RELENG_5_3 | +5.3-RELEASE | +Extended | +November 6, 2004 | +October 31, 2006 | +
| RELENG_5_4 | +5.4-RELEASE | +Normal | +May 9, 2005 | +May 31, 2006 | +
Older releases are not maintained and users are strongly + encouraged to upgrade to one of the supported releases mentioned + above.
+ +Some statistics about advisories released during 2002:
+ +Advisories are sent to the following FreeBSD mailing lists:
+Advisories are always signed using the FreeBSD Security Officer + PGP + key and are archived, along with their associated + patches, at our FTP CERT + repository. 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 FTP + site):
+ + &advisories.html.inc; + + &footer; +