diff --git a/en/internal/machines.sgml b/en/internal/machines.sgml index 5b45bb0cbd..c202c6e4f2 100644 --- a/en/internal/machines.sgml +++ b/en/internal/machines.sgml @@ -1,411 +1,411 @@ - + %navincludes; %includes; ]> &header;

This page documents, for those with accounts on the FreeBSD.org network, just what machine resources are currently available and the sorts of jobs they are being provided for.

For a list of SSH host keys and their fingerprints for the public FreeBSD.org machines, please see this file.

All host names in the FreeBSD.org domain

Host OS Purpose Owner(s)
beast 5-STABLE Alpha box for FreeBSD/alpha testing obrien/peter
builder 6-STABLE BSD/OS source holder
Build box for the FreeBSD documentation for the FTP site		 committers
freefall 6-STABLE GNATS/shell logins committers
ftp-master 4-STABLE ftp master (stage server) peter/kuriyama/obrien/steve
gohan10-17 6-STABLE/7-CURRENT Ports building cluster ports team
gohan20-39 6-STABLE/7-CURRENT Ports building cluster ports team
hub 6-STABLE Mail services postmaster
mx1 4-STABLE Inbound mail services dhw/peter
mx2 4-STABLE Outbound mail services dhw/peter
ncvsup (cvsup10) 6-STABLE Public CVSup mirror kuriyama
ns0 4-STABLE FreeBSD.org domain master dg/ps/peter
panther -CURRENT Reference machine for testing sparc64 changes (currently down) committers
pluto1 -CURRENT Reference machine for testing ia64 changes committers
pluto2 6-STABLE Reference machine for testing ia64 changes committers
pointyhat -CURRENT All architectures package build master ports team
ref4 4-STABLE Reference machine for testing 4-STABLE changes committers
repoman 6-STABLE CVS master repository peter
sledge -CURRENT Reference machine for testing amd64 changes committers
spit (cvsup-master) 6-STABLE CVSup master mirror kuriyama
www 4-STABLE Web services webmaster

Hardware configurations

Host Type Hardware
beast API UP2000 2 x 833MHz Alpha 21264 with 8MB L2cache, 2GB mem, Adaptec 2940U2W SCSI controller, 2 SCSI U160 drives, 3COM 3c905B NIC.
builder Intel x86 800MHz Pentium III, 512MB mem, 40GB Seagate ATA drive, Intel EtherExpress Pro 10/100B NIC.
freefall Intel x86 800MHz Pentium III, 1024MB mem, Mylex DAC960 PCI SCSI RAID controller, 5x18GB SCSI U2W drives, Intel EtherExpress Pro 10/100B NIC.
ftp-master Intel x86 2 x 850MHz Pentium III, 2048MB mem, 3ware 8-port IDE controller (twe), Intel EtherExpress Pro 10/100B NIC.
gohan10-17 Intel x86 800MHz Pentium III, 512MB mem, Intel ICH ATA66 controller, 1x30GB ATA66 drive, Intel EtherExpress Pro 10/100B NIC.
gohan20-39    
hub Intel x86 2 x 600MHz Pentium III, 1GB mem, Mylex DAC960 PCI SCSI RAID controller, 3x9GB SCSI WIDE drives, Intel EtherExpress Pro 10/100B NIC.
mx1    
mx2 Intel x86 850MHz FC-PGA Pentium III, 512MB mem, LSI 53C1010 U160 SCSI, 1x18GB 10K RPM U160 SCSI drive, Intel EtherExpress Pro 10/100B NIC.
ncvsup (cvsup10)    
ns0    
panther Sun OEM ATX Panther board 300 MHz UltraSparc-IIi, 512MB mem, 2x9GB 10K RPM Ultra2 SCSI drives, Sun HME 10/100B NIC.
pluto1, pluto2 HP rx2600 (IA-64) 2x900MHz Itanium2 (McKinley) - HP zx1 (pluto) chipset, 2048MB mem (only 1024MB enabled), LSILogic 1030 U320 SCSI controller (mpt), 1x36GB 10K RPM U160 SCSI drive, Broadcom BCM5701 10/100/1000 NIC.
pointyhat Intel x86 MP 2x1266MHz Pentium III, 2048MB mem, 3ware 4-port IDE controller (twe), 4x160GB UltraATA drives in RAID 1+0 mode. Intel EtherExpress Pro 10/100B NIC.
ref4 Intel x86 550MHz FC-PGA Celeron, 1024MB mem, 1x17GB SCSI drive, Intel EtherExpress Pro 10/100B NIC.
repoman AMD64 MP 2x2.4GHz Opteron 280 (dual core), 8192MB mem, HP Smart Array 6i RAID controller, Broadcom BCM5704C Gigabit NIC.
sledge Rioworks HDAMA (AMD64) 2x1.8GHz Opteron 244 - AMD 8111/8131 chipset, 8192MB mem, 1x40GB Seagate ST340014A IDE drive, Broadcom BCM5703 10/100/1000 NIC.
spit (cvsup-master)    
www Intel x86 2 x 600MHz Pentium III, 1024MB mem, 3ware 4-port IDE controller (twe), Intel EtherExpress Pro 10/100B NIC.

All machines are connected at 100Mbit/sec full-duplex to a dedicated Cisco 2948G switch with redundant gigabit uplinks. Internet connectivity and colocation is provided by Yahoo!. All systems have logged serial consoles and remote power control.

Ports-building cluster in Korea

Host OS Purpose Owner(s)
dalki, dosirak, haessal 5-CURRENT Ports building cluster ports team

Hardware configurations

Host Type Hardware
dalki, haessal Intel x86 2x2.20GHz Pentium 4 Xeon, 2GB mem, Adaptec aic7899 Ultra160 SCSI adapter, 1x36GB SCSI-3 drive, 2xIntel EtherExpress Pro 10/100B NIC.
dosirak Intel x86 2x2.20GHz Pentium 4 Xeon, 4GB mem, Adaptec aic7899 Ultra160 SCSI adapter, 1x36GB SCSI-3 drive, 2xIntel EtherExpress Pro 10/100B NIC.

All machines are connected at 100Mbit/sec full-duplex to a dedicated Cisco 2950G switch with redundant gigabit uplinks. Internet connectivity and colocation is provided by Yahoo! Korea and KIDC. The machines are provided by eSlim Korea.

Administrative Policies

If the machine in question is "owned" by someone specific, please direct queries to them first when asking about administrative issues, this includes changes to user accounts or filesystem layout.

All new user accounts must be cleared with the admin staff, admin@FreeBSD.org, and are given +href="mailto:clusteradm@FreeBSD.org">clusteradm@FreeBSD.org, and are given only to FreeBSD developers, either in the docs, ports or general src hacking category. Accounts may be given to non-project developers if they have a specific need to test something of a truly experimental nature and need access to a FreeBSD machine for the purpose. Accounts are not given to the general public for "vanity domain" mail or other such uses. It would be a waste of time to ask. Thanks.

FreeBSD Internal Home &footer; diff --git a/en/security/security.sgml b/en/security/security.sgml index e67895ad10..e15fffc0a2 100644 --- a/en/security/security.sgml +++ b/en/security/security.sgml @@ -1,355 +1,355 @@ - + %navincludes; %includes; %developers; ]> - + &header;

Introduction

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.

Table of Contents

All FreeBSD Security issues should be reported to the FreeBSD Security Team or, if a higher level of confidentiality is required, to the Security Officer Team. All reports should at least contain:

After this information has been reported the Security Officer or a Security Team delegate will get back with you.

The FreeBSD Security Officer and the Security Officer Team

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 <secteam@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.

Information handling policies

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 + href="mailto:clusteradm@FreeBSD.org">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.

FreeBSD Security Advisories

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.)

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.

Early adopter
Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release.
Normal
Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release.
Extended
Selected releases will be supported by the Security Officer for a minimum of 24 months after the release.

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_11 4.11-RELEASE Extended January 25, 2005 January 31, 2007
RELENG_5 n/a n/a n/a May 31, 2008
RELENG_5_3 5.3-RELEASE Extended November 6, 2004 October 31, 2006
RELENG_5_4 5.4-RELEASE Normal May 9, 2005 October 31, 2006
RELENG_5_5 5.5-RELEASE Extended May 25, 2006 May 31, 2008
RELENG_6 n/a n/a n/a last release + 2 years
RELENG_6_0 6.0-RELEASE Normal November 4, 2005 November 30, 2006
RELENG_6_1 6.1-RELEASE Extended May 9, 2006 May 31, 2008

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;