diff --git a/en/security/security.sgml b/en/security/security.sgml index 7ef790649d..c1e9a0b483 100644 --- a/en/security/security.sgml +++ b/en/security/security.sgml @@ -1,897 +1,898 @@ - + %includes; ]> - + &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.
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, the Deputy Security Officer, and two Core Team members. Therefore, messages sent to the <security-officer@FreeBSD.org> mail alias are currently delivered to:
Jacques Vidrine <nectar@FreeBSD.org> | Security Officer |
Chris Faulhaber <jedgar@FreeBSD.org> | Deputy Security Officer |
Robert Watson <rwatson@FreeBSD.org> | FreeBSD Core Team member, Release Engineering liaison, TrustedBSD Project liaison, system security architecture expert |
Warner Losh <imp@FreeBSD.org> | FreeBSD Core Team liaison, Security Officer Emeritus |
The Security Officer is supported by the Security Officer Team <security-team@FreeBSD.org>, a group of committers selected by the Security Officer. The current make up of the team is as follows:
Bill Fumerola <billf@FreeBSD.org> | FreeBSD Infrastructure liaison |
Daniel Harris <dannyboy@FreeBSD.org> | Doc and ports committer |
Trevor Johnson <trevor@FreeBSD.org> | ports committer |
Kris Kennaway <kris@FreeBSD.org> | Port Manager liaison, Security Officer Emeritus |
Wes Peters <wes@FreeBSD.org> | FreeBSD Core Team member; former security software researcher and developer for the US Air Force, Axent Technologies/Symantec, Intel, and Alcatel Internetworking. |
Guido van Rooij <guido@FreeBSD.org> | Security Officer Emeritus |
Dag-Erling Smorgrav <des@FreeBSD.org> |
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 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.
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.
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.
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.6-STABLE.
Each FreeBSD Release has an associated Security Branch. The Security Branch tags have names like RELENG_4_6. The corresponding builds have names like FreeBSD 4.6-RELEASE-p7.
Each branch is supported by the Security Officer for a limited time only, typically through 12 months after the release. The 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 | Estimated EoL |
---|---|---|
RELENG_4 | n/a | December 31, 2003 |
RELENG_4_6 | 4.6-RELEASE | May 31, 2003 |
RELENG_4_7 | 4.7-RELEASE | September 30, 2003 |
RELENG_4_8 | 4.8-RELEASE | March 31, 2004 |
RELENG_5_0 | 5.0-RELEASE | June 30, 2003 |
Older releases are not maintained and users are strongly encouraged to upgrade to one of the supported releases mentioned above.
Like all development efforts, security fixes are first brought into the FreeBSD-current 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.
Some statistics about advisories released during 2001:
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):
If you are administering or using any number of FreeBSD systems, you should probably be subscribed to one or more of the following lists:
freebsd-security General security related discussion freebsd-security-notifications Security notifications (moderated mailing list)Send mail to majordomo@FreeBSD.ORG with
subscribe <listname> [<optional address>]in the body of the message in order to subscribe yourself. For example:
% echo "subscribe freebsd-security" | mail majordomo@FreeBSD.organd if you would like to unsubscribe from a mailing list:
% echo "unsubscribe freebsd-security" | mail majordomo@FreeBSD.org
char buf[1024]; struct foo { ... }; ... BAD: xxx(buf, 1024) xxx(yyy, sizeof(struct foo)) GOOD: xxx(buf, sizeof(buf)) xxx(yyy, sizeof(yyy))Be careful though with sizeof of pointers when you really want the size of where it points to!
A useful auditing tool is the its4 port, located in /usr/ports/security/its4/. This is an automated C code auditor which highlights potential trouble-spots in the code. It is a useful first-pass tool, but should not be relied upon as being authoritative, and a complete audit should include human examination of the entire code.
For more information on secure programming techniques and resources, see the How to Write Secure Code resource center.
There are several steps one must take to secure a FreeBSD system, or in fact any Unix system:
There is also a FreeBSD Security How-To available which provides some advanced tips on how to improve security of your system. You can find it at http://www.FreeBSD.org/~jkb/howto.html.
Security is an ongoing process. Make sure you are following the latest developments in the security arena.