SGI IRIX version 6.5.13
Validation Report
National Information Assurance Partnership
®
TM
Common Criteria Evaluation and Validation Scheme
Validation Report
Silicon Graphics, Inc.
IRIX Version 6.5.13
with Patches 4354, 4451, and 4452
Report Number: CCEVS-VR-02-0019
Dated: 30 April 2002
National Institute of Standards and Technology National Security Agency
Information Technology Laboratory Information Assurance Directorate
100 Bureau Drive 9800 Savage Road STE 6740
Gaithersburg, MD 20899 Fort George G. Meade, MD 20755-6740
SGI IRIX version 6.5.13
Validation Report
ACKNOWLEDGEMENTS
Validation Team
Bradford O’Neill
Frank Belvin
Jean Hung
The MITRE Corporation
Bedford, Massachusetts
Janine Pedersen
National Security Agency
Ft. George G. Meade, Maryland
Common Criteria Testing Laboratory
Science Applications International Corporation
Columbia, Maryland
SGI IRIX Version 6.5.13
Validation Report
Table of Contents
1 EXECUTIVE SU M M A R Y ..........................................3
2 IDENTIFICATION...............................................3
3 SECURITY POLICY .............................................4
4 ASSU MPTIONS AND CLARIFICATION OF SCOPE ......................5
4.1 USAGE ASSUMPTIONS ....................................................................................................... 5
4.2 ENVIRONMENTAL ASSUMPTIONS...................................................................................... 6
4.3 CLARIFICATION OF SCOPE................................................................................................. 6
5 ARCHITECTURAL INFOR M ATION .................................6
6 DOCU M ENTATION .............................................7
7 IT PRODUCT TESTING...........................................8
7.1 DEVELOPER TESTING ........................................................................................................ 8
7.2 EVALUATOR TESTING ....................................................................................................... 8
8 EVALUATED CONFIGURATION ...................................9
9 RESULTS OF THE EVALUATION ...................................9
9.1 EVALUATION OF THE IRIX SECURITY TARGET (ST) (ASE)............................................. 9
9.2 EVALUATION OF THE CM CAPABILITIES (ACM) .............................................................. 9
9.3 EVALUATION OF THE DELIVERY AND OPERATION DOCUMENTS (ADO).......................... 9
9.4 EVALUATION OF THE DEVELOPMENT (ADV) ................................................................... 9
9.5 EVALUATION OF THE GUIDANCE DOCUMENTS (AGD)................................................... 10
9.6 EVALUATION OF THE LIFE CYCLE SUPPORT ACTIVITIES (ALC) .................................... 10
9.7 EVALUATION OF THE TEST DOCUMENTATION AND THE TEST ACTIVITY (ATE)............ 10
9.8 VULNERABILITY ASSESSMENT ACTIVITY (AVA)........................................................... 10
9.9 SUMMARY OF EVALUATION RESULTS ............................................................................ 10
10 VALIDATOR CO M M E NTS...................................... 10
11 SECURITY TARGET .......................................... 11
12 GL OSSARY ................................................. 11
13 BIBLIOGRAPHY ............................................. 13
ANNEX A ....................................................... 14
A.1 HARDWARE ........................................................................................................................ 14
A.2 KERNEL-MODE ................................................................................................................... 14
A.2.1 Process Management................................................................................................... 14
A.2.2 File Management......................................................................................................... 14
A.2.3 NFS .............................................................................................................................. 14
A.2.4 Input/Output................................................................................................................. 15
A.2.5 Memory Management .................................................................................................. 15
A.2.6 Auditing........................................................................................................................ 15
A.2.7 Interprocess Communication....................................................................................... 15
A.2.8 Network........................................................................................................................ 15
A.3 USER-MODE........................................................................................................................ 15
A.3.1 User Network Services................................................................................................. 15
A.3.2 Identification and Authentication ................................................................................ 16
A.3.3 Printer Subsystem ........................................................................................................ 16
A.3.4 Batch Processing ......................................................................................................... 16
A.3.5 Electronic Mail Subsystem........................................................................................... 16
A.3.6 Trusted Commands ...................................................................................................... 16
Page i
i
SGI IRIX Version 6.5.13
Validation Report
LIST OF FIGURES
Figure 1: Architectural Overview................................................................................................... 7
LIST OF TABLES
Table 1: Evaluation Identifiers ....................................................................................................... 4
Page ii
ii
SGI IRIX Version 6.5.13
Validation Report
1 EXECUTIVE SU M M A RY
This report documents the NIAP validators’ assessment of the CCEVS evaluation of SGI IRIX Version 6.5.13. It
presents the evaluation results, their justifications, and the conformance result.
The evaluation was performed by Science Applications International Corporation (SAIC) and was completed on 30 April
2002. The information in this report is largely derived from the Evaluation Technical Report (ETR) written by SAIC and
submitted to the validators. The evaluation determined the product conforms to the CC Version 2.1, Part 2 and Part 3 to
meet the requirements of Evaluation Assurance Level (EAL)3, resulting in a “pass” in accordance with CC Part 1
paragraph 175. The Target of Evaluation (TOE) also conforms to the Controlled Access Protection Profile (CAPP),
version 1.d.
The IRIX system under evaluation is a system of Silicon Graphics Computer Systems, Inc. (SGI) Origin200
workstations and Origin 3000 servers connected via an Ethernet. These UNIX-based multi-user, multi-tasking
workstations provide high-performance, general-purpose computing. The processor of the workstation and server is the
SGI MIPS R12000.
IRIX supports a discretionary access control (DAC) policy; an identification and authentication capability to mediate and
validate requests for entry into the system; and an audit trail capability.
The administrator guidance documents and product release notes provide the administrator with specific instructions to
ensure that the product is installed in an appropriate environment.
The validation team monitored the activities of the evaluation team, observed evaluation testing activities, provided
guidance on technical issues and evaluation processes, reviewed selected evaluation evidence, and reviewed the
individual work units and successive versions of the ETR. The validation team found that the evaluation showed that the
product satisfies all of the functional requirements and assurance requirements stated in the Security Target (ST).
Therefore the validation team concludes that SAIC's findings are accurate, the conclusions justified, and the
conformance results correct.
Disclaimers: The information contained in this Validation Report is not an endorsement of IRIX by any agency of the
U.S. Government and no warranty of IRIX is either expressed or implied.
2 IDENTIFICATION
The CCEVS is a joint National Security Agency (NSA) and National Institute of Standards and Technology (NIST)
effort to establish commercial facilities to perform trusted product evaluations. Under this program, security evaluations
are conducted by commercial testing laboratories called Common Criteria Testing Laboratories (CCTLs) using the
Common Evaluation Methodology (CEM) for Evaluation Assurance Level (EAL) 1 through EAL 4 in accordance with
National Voluntary Laboratory Accreditation Program (NVLAP) accreditation.
The NIAP Validation Body assigns validators to monitor the CCTLs to ensure quality and consistency across
evaluations. Developers of information technology products desire a security evaluation contract with a CCTL and pay a
fee for their product’s evaluation. Upon successful completion of the evaluation, the product is added to NIAP’s
Validated Products List. Table 1 provides information needed to completely identify the product, including:
• the Target of Evaluation (TOE): the fully qualified identifier of the product as evaluated,
• the Security Target (ST), describing the security features, claims, and assurances of the product,
• the conformance result of the evaluation,
• the organizations and individuals participating in the evaluation.
3
SGI IRIX Version 6.5.13
Validation Report
Table 1: Evaluation Identifiers
Item Identifier
Evaluation Scheme
United States NIAP Common Criteria Evaluation and Validation
Scheme
Target of Evaluation IRIX Version 6.5.13 with Patches 4354, 4451, and 4452
Protection Profile
Controlled Access Protection Profile (CAPP), version 1.d, October 8,
1999
Security Target SGI IRIX Version 6.5.13, Security Target Version 1.9
Evaluation Technical Report
Evaluation Technical Report for the IRIX version 6.5.13, with Patches
4354, 4451, and 4452, and the Trusted IRIX/CMW version 6.5.13,
with Patches 4354, 4451, 4452, 4373, and 4473, Version 0.2, April
11, 2002.
Conformance Result Part 2 conformant, Part 3 conformant, and EAL 3
Version of CC
CC Version 2.1 [1], [2], [3], [4] and all applicable National and
International Interpretations effective on November 21, 2000
Version of CEM
CEM Version 1.0 [5], [6] and all applicable National and International
Interpretations effective on November 21, 2000
Sponsor Silicon Graphics, Inc.
Developer Silicon Graphics, Inc.
Evaluators
Science Applications International Corporation
Ms. Cynthia Reese
Ms. Shukrat A. Abbas
Mr. James L. Arnold Jr.
Ms. Farideh Moghadami
Ms. Evencie Pierre
Government Participants
Ms. Marvella Towns
Validators
Mr. Bradford O’Neill (The MITRE Corporation)
Mr. Frank Belvin (The MITRE Corporation)
Mrs. Jean Hung (The MITRE Corporation)
Mrs. Janine Pedersen (NSA)
3 SECURITY POLICY
IRIX is a commercial UNIX operating system that provides identification and authentication, DAC, audit, and object
reuse. The IRIX kernel is responsible for providing memory management, process management, a consistent interface to
system hardware, and mediating access to protected resources.
Discretionary Access Control
IRIX supports traditional file permission bits working in concert with the more versatile Access Control Lists (ACLs).
Discretionary Access Control (DAC) permissions are defined by the user who owns the file in question. For example, if
a user has a personal file in his or her home directory, that user can set the DAC permissions to allow no other users on
4
SGI IRIX Version 6.5.13
Validation Report
the system to view, copy, or edit that file. Default DAC permissions for newly created files are set via the umask
command.
Thus, to gain access to a file that was created by another user, a user must have set the DAC permissions on the file to
allow others to access it. DAC permissions should be set in accordance with site security policies.
Default DAC permissions for newly created files depend on the umask and on any default ACL entries found in the
containing directory.
Identification and Authentication
The Identification and Authentication (I&A) mechanism controls user access to the system. In common terms, the I&A
mechanism is the login procedure. This subsystem is always active if the system is running, and it is impossible to have
any contact with the system without first logging in through the I&A system.
The improved I&A facilities of IRIX allow the administrator to be certain that the people on the system are authorized
users and that private password integrity is maintained to the highest possible levels.
Under IRIX, encrypted passwords are stored separately from other user identification information. This separate location
is hidden from normal user access, so the process of a systematic dictionary encryption hunt for a password is precluded.
User clearance information is also stored in a hidden or shadow file. Under IRIX, the /etc/password file does not contain
the encrypted password; only the shadow password file contains that information.
System Audit Trail
A foundation of IRIX is the system audit trail. The system audit trail provides a means for the system administrator to
oversee each important event taking place on the system. The audit trail is useful for tracking changes in sensitive files
and programs and for identifying inappropriate use of the system.
The audit trail is generated by additional code in the operating system kernel that notes specific important events, such as
file creation, file changes, file removal, invocation of programs, and the login and logout events.
The audit subsystem allows the administrator to create a dynamic record of the system's activity. Audit records of
security relevant events are generated on each workstation of the IRIX system. These records contain the initial login
identifier of the user who initiated the audited event and allow the administrator to hold each user strictly accountable for
his or her actions. IRIX commands allow the system administrator to selectively audit events. SGI provides tools to
reduce the audit logs for analysis. The audit system is completely configurable at any time by the audit administrator.
Audit information must be carefully gathered and protected so that actions affecting security can be traced to the
responsible party. IRIX records the occurrences of security-relevant events in an audit log. For each event audited, the
system records the date and time of the event, the initiating user, the type of event, the success or failure of the event, and
the name and security classification of the files or programs used.
Object Reuse Policy
To preclude accidental disclosure of data, display memory and long-term data storage are subject to an object reuse
policy and implementation. For example, all system memory is always automatically cleared before it is allocated to
another program. Surrendered disk space is also cleaned before it is reallocated.
4 ASSU M PTIONS AND CLARIFICATION OF SCOPE
4
.1 Usage Assumpt
ions
The evaluation made the following assumptions concerning product usage:
5
SGI IRIX Version 6.5.13
Validation Report
• There will be one or more competent individuals assigned to manage the TOE and the security of the information it
contains.
• The system administrative personnel are not careless, willfully negligent, or hostile, and will follow and abide by the
instructions provided by the administrator documentation.
• Authorized users possess the necessary authorization to access at least some of the information managed by the TOE
and are expected to act in a cooperating manner in a benign environment.
• The TOE must operate under a single management domain with each TSF sharing the same identification and
authentication database.
4
.2 Environmenta
l Assumpt
ions
The evaluation made the following environmental assumptions:
• The processing resources of the TOE will be located within controlled access facilities which will prevent
unauthorized physical access.
• The TOE hardware and software critical to security policy enforcement will be protected from unauthorized
physical modification.
• Any other systems with which the TOE communicates are assumed to be under the same management control and
operated under the same security policy constraints. CAPP-conformant TOEs are applicable to networked or
distributed environments only if the entire network operates under the same constraints and resides within a single
management domain. There are no security requirements which address the need to trust external systems or the
communications links to such systems.
• All connections to peripheral devices reside within the controlled access facilities. CAPP-conformant TOEs only
address security concerns related to the manipulation of the TOE through its authorized access points. Internal
communication paths to access points such as terminals are assumed to be adequately protected.
4
.3 Clar
i
f
i
ca
t
i
on o
f Scope
All TOE security objectives were derived from the ST’s organizational security policies and the ST did not list any
threats. Therefore, there are no threats that were not countered by the TOE.
5 ARCHITECTURAL INFOR MATION
The system under evaluation is a system of Silicon Graphics Computer Systems, Inc. (SGI) Origin200 workstations and
the Origin 3000 servers connected via an Ethernet. The workstations and servers run the IRIX operating system. The
processor of the IRIX system workstation and server is the SGI MIPS R12000.
The Origin 3000 Series is a family of modular computer server systems. The various internal components of the various
Origin 3000 servers and their functions are divided into separate units called "bricks". These bricks are housed in short
or tall rack enclosures. The Origin200 workstation is a multiprocessor system that consists of one or two chassis, which
are called modules. The Origin200 GIGAchannel uses an additional chassis to provide extra peripheral device interfaces.
In the evaluated configuration, the following peripherals can be attached to a computer system: fixed disk drives, SCSI
tape drive, CD-ROM drive, floppy disk drive, and network interface. In addition, a dumb terminal and/or dumb printer
can be attached to an Origin200 computer system.
IRIX is a UNIX-based multi-user, multi-tasking operating system that supports the following security policies:
discretionary access control; identification and authentication; auditing, and object reuse. The services provided by the
IRIX system have been divided into logical subsystems. Each subsystem is responsible for policy enforcement or for
maintaining information used by other subsystems for policy enforcement. Figure 1 Architectural Overview presents an
architectural overview of the product. A more detailed description of each subsystem may be found in Annex A. The
subsystems are organized into following three portions: hardware, kernel-mode, and user-mode.
6
SGI IRIX Version 6.5.13
Validation Report
The IRIX system executes instructions in two broad domains. Commands and applications execute in user-mode. In this
mode, the memory management system and hardware restrictions on instruction execution isolate processes from each
other, from operating system control data, and from direct hardware access. This establishes a strong separation of the
instruction streams and data contained in one process from those found in another process.
A process may initiate an operating system request from user-mode through the system call trap mechanism. A system
call trap is a software interrupt operation that causes a context switch from user-mode into kernel-mode. In kernel-mode,
only defined code sequences are executed to perform the requested function. This kernel code sequence, however, has
unrestricted direct access to kernel control data and the hardware.
Hardware
Kernel Mode
User Mode
IPC
Audit
Support
Process
Management
Memory
Management
File
Subsystem
I/O
Subsystem
Network
Subsystem
Printer
Subsystem
Batch
Processing
Subsystem
I&A
Subsystem
Trusted
Commands
Audit
Programs
User Network
Subsystem
NFS
Electronic
Mail
Figure 1: Architectural Overview
6 DOCUM E NTATION
This section provides a complete listing of the documentation provided with the product by the developer to the
consumer.
1) Administrative Guidance
a. IRIX Admin: Backup, Security, and Accounting, 007-2862-004
b. IRIX Admin Release Notes for Release 6.5.13 Common Criteria Evaluation
c. IRIX 6.5 man pages (only commands referenced in the Administrative Guidance)
2) User Guidance
a. Trusted IRIX/CMW Security Features User’s Guide, 007-3300-003
7
SGI IRIX Version 6.5.13
Validation Report
b. IRIX Security Features User's Guide Release Notes for Release 6.5.13 Common Criteria Evaluation
version 1.0
c. IRIX 6.5 man pages (only commands referenced in the User Guidance)
3) Delivery and Installation
a. Trusted IRIX/IRIX Delivery and Installation, Revision 3.0, 4/9/02
7 IT PRODUCT TESTING
7
.1 Deve
loper Tes
t
ing
The developer maintains a suite of tests to demonstrate that the product satisfies the claims that were made in the
Security Target. This testing was primarily accomplished through the use of an automated test suite. The test driver
executes individual test scripts and saves their output to a file. The test driver then compares the each test’s output to its
golden file and will report any significant differences as a test failure. The test’s output contains enough information to
describe what action took place, the current environment including the subject and object details, and the result. The
golden output file is an output file from previous test execution that contains the expected output for the test. The
developers manually examined each golden file to confirm that the test’s objectives were satisfied. The automated tests
were supplemented with a small number of manual tests.
The developer used a gray box methodology. Basic tests were run against every external security function interface. One
interface was used for more extensive testing of the capability, DAC, and audit mechanisms. Auditing records, where
required, were captured for a successful case and an unsuccessful case. In general, to demonstrate the expected test
behavior both the successful and unsuccessful outcomes are executed. System calls and commands which modify
security attributes of objects also included functionality tests. The implementation of these tests demonstrates the effect
of the function when successfully called. The majority of tests fall under one of the following categories:
• The calling process has DAC access to the object or the appropriate DAC capability.
• The calling process has the required capabilities to perform the action, in addition to DAC capabilities that may be
required.
• An audit record is generated when performing the action.
• The function creates a new object or modifies an object's attributes.
7
.2 Evaluator Tes
t
ing
The evaluators performed almost all of the tests in the developer’s test suite. The evaluation team installed the IRIX
operating system on two computer systems: an Origin200 workstation and an Origin 3000 server. The team ran all tests
in developer’s automated test suite on both the Origin200 and the Origin 3000 computer systems. The team executed all
of the automated NFS tests using the Origin200 as the client and the Origin 3000 as the server. The evaluation team also
performed a representative sample of the manual tests on the Origin200. Approximately 20% of the manual tests,
covering 8 subsystems, were executed. The team examined the test output to confirm that the actual test results were
consistent with the expected results.
The evaluators performed some independent product testing of their own design. Through analysis of the developer’s test
suite, the evaluators determined that the developer testing was thorough enough to confirm that the TOE provided the
functionality claimed in the ST with only a few exceptions. Hence, the evaluators did not develop a large number of
independent tests. Based on a review of the subsystem specifications and the developer’s test suite, the evaluation team
identified specific functionality for additional independent testing. The team tests demonstrated functionality across nine
of the twelve security functions described in the Security Target. Included in the nine, were the access control (DAC),
audit, and identification and authentication functions. The evaluation team also developed penetration tests based upon
their review of the vendor’s vulnerability assessment. Test procedures and expected results were developed for each test.
After each test was performed, the evaluators confirmed that the actual results matched the expected results.
8
SGI IRIX Version 6.5.13
Validation Report
The evaluation team reviewed all of the security functions and the mapping between security functions and tests and
concluded all security functions were appropriately tested. The evaluators also manually examined each golden file to
confirm that the test’s objectives were satisfied. The results of the evaluation team tests and the evaluation penetration
tests demonstrated the product behaved as claimed in the Security Target. The testing found that the product was
implemented as described in the functional specification and did not uncover any undocumented interfaces or other
security vulnerabilities.
8 EVALUATED CONFIGURATION
The TOE hardware consists of Origin200 workstations and Origin 3000 servers connected via Ethernet. The TOE was
evaluated for two basic hardware configurations. In both configurations the IRIX operating system was installed and
configured according to the Installation and Delivery document. In one configuration, the hardware was an Origin200
workstation. In the other, the hardware was an Origin 3000 server. The network interfaces for both hardware
configurations were evaluated. The physical Ethernet/IP network components were not evaluated and are regarded as an
internal communication path that must be adequately protected. The environmental and usage assumptions described in
this report are applicable to all evaluated configurations.
9 RESULTS OF THE EVALUATION
A verdict for an assurance component is determined by the resulting verdicts assigned to the corresponding evaluator
action elements. The evaluation was conducted based upon CC version 2.1 [1], [2], [3] [4] and CEM version 1.0 [5], [6]
and all applicable National and International Interpretations in effect on November 21, 2000. The evaluation determined
the product to be Part 2 conformant, and to meet the Part 3 Evaluation Assurance Level (EAL 3) requirements. The
details of the evaluation are recorded in the Evaluation Technical Report [8] which is controlled by SAIC.
9
.1 Evaluat
ion o
ftheI
RIX Secur
i
ty Target(ST)(ASE)
The evaluation team applied each ASE CEM work unit. The ST evaluation ensured the ST contains description of the
environment in terms of policies and assumptions, a statement of security requirements claimed to be met by the IRIX
product that are consistent with the Common Criteria, and product security function descriptions that support the
requirements. Additionally, the evaluation team ensured the ST is consistent and compliant with the CAPP.
9
.2 Evaluat
ion o
fthe CM capabi
l
i
t
i
e
s(ACM)
The evaluation team applied each EAL 3 ACM work unit. The ACM evaluation ensured the TOE is identified such that
the consumer is able to identify the evaluated TOE. The evaluation team ensured the adequacy of the procedures used
by the developer to control and track changes made to the TOE implementation, design documentation, test
documentation, user and administrator guidance, and the CM documentation. The procedures reduce the risk that
security flaws exist in the TOE implementation or TOE documentation.
9
.3 Evaluat
ion o
fthe De
l
ivery and Operat
i
on documents(ADO)
The evaluation team applied each EAL 3 ADO work unit. The ADO evaluation ensured the adequacy of the procedures
to deliver, install, and configure the TOE securely.
9
.4 Evaluat
ion o
fthe Deve
lopment(ADV)
9
SGI IRIX Version 6.5.13
Validation Report
The evaluation team applied each EAL 3 ADV work unit. The evaluation team assessed the design documentation and
found it adequate to aid in understanding how the TSF provides the security functions. The design documentation
consists of a high-level design document and a subsystem specification per subsystem. Section 5, Architectural
Information, includes a description of each subsystem. The collection of subsystem specifications and the high-level
design document describe the external interfaces of the TOE and the architecture of the TOE in terms of internal
subsystems. The subsystem specifications and the high-level design document were determined by the evaluation team
to sufficiently meet the requirements of a functional specification and a high level design. The evaluation team also
ensured that the correspondence analysis between the design abstractions correctly demonstrated that the lower
abstraction was a correct and complete representation of the higher abstraction.
9
.5 Evaluat
ion o
fthe Guidance Documents(AGD)
The evaluation team applied all AGD EAL 3 CEM work units. The evaluation team ensured the adequacy of the user
guidance in describing how to use the operational TOE. Additionally, the evaluation team ensured the adequacy of the
administrator guidance in describing how to securely administer the TOE.
9
.6 Evaluat
ion o
fthe Li
f
e Cyc
leSupportAct
iv
i
t
i
e
s(ALC)
The evaluation team applied all ALC EAL 3 CEM work units. The evaluation team ensured the adequacy of the
developer procedures to protect the TOE and the TOE documentation during TOE development and maintenance to
reduce the risk of the introduction of TOE exploitable vulnerabilities during TOE development and maintenance.
9
.7 Evaluat
ion o
fthe Tes
t Documentat
ion andthe Tes
t Act
iv
i
t
y(ATE)
The evaluation team applied all EAL 3 ATE CEM work units. The evaluation team ensured that the TOE performed as
described in the design documentation and demonstrated that the TOE enforces the security functional requirements.
Specifically, the evaluation team ensured that the vendor test documentation sufficiently addresses the security functions
as described in the subsystem specifications (functional specification and high level design specification). The
evaluation team performed a sample of the vendor test suite, and devised an independent set of team test and penetration
tests. The vendor tests, team tests, and penetration tests substantiated the security functional requirements in the ST.
9
.8 Vulnerab
i
l
i
ty Assess
ment Act
i
v
i
ty(AVA)
The evaluation team applied all AVA EAL 3 CEM work units. The evaluation team ensured that the TOE does not
contain exploitable flaws or weaknesses in the TOE based upon the vendor strength of function analysis and the vendor
vulnerability analysis, and the evaluation team’s misuse analysis and performance of penetration tests.
9
.9 Sum mary o
f Eva
luat
ion Resu
l
t
s
The evaluation team’s assessment of the evaluation evidence demonstrates that the claims in the ST are met.
Additionally, the evaluation team’s performance of a subset of the vendor tests suite, independent tests, and penetration
test also demonstrate the accuracy (or veracity) of the claims in the ST.
10 VALIDATOR CO M M E NTS
The CC's ADV and ATE assurance requirements ensure that the TOE performs as described in its design documents and
that the design documents are consistent with claims made in the ST. For the IRIX evaluation the functional
specifications for the TSFI consisted of subsystem specifications supplemented by the traditional UNIX "man" pages
with the subsystem specifications given precedence. Therefore, the "man" pages that are provided to the end-user should
10
SGI IRIX Version 6.5.13
Validation Report
not be viewed as authoritative. Furthermore, the subsystem specifications did not explicitly reference the POSIX
P1003.1e standard. Therefore, any statements regarding the implementation of POSIX P1003.1e features (e.g.,
capabilities and access control lists) are for informational use only and do not imply that the TOE was tested for
conformance with the POSIX P1003.1e standard.
11 SECURITY TARGET
The Security Target, "Silicon Graphics, Inc. IRIX Version 6.5.13, Security Target Version 1.9, May 1, 2002", is included
here by reference.
12 GLOSSARY
ACL Access Control List
CAPP Controlled Access Protection Profile
CC Common Criteria
CCEVS Common Criteria Evaluation and Validation Scheme
CCTL Common Evaluation Testing Laboratory
CEM Common Evaluation Methodology
CI Configuration Items
DAC Discretionary Access Control
EAL Evaluation Assurance Level
ETR Evaluation Technical Report
I&A Identification and Authentication
I/O Input/Output
IP Internet Protocol
IPC Interprocess Communications
MAC Mandatory Access Control
MRA Mutual Recognition Arrangement
NIAP National Information Assurance Program
NIST National Institute of Standards & Technology
NFS Network File System
NVLAP National Voluntary Laboratory Accreditation Program
OR Observation Report
11
SGI IRIX Version 6.5.13
Validation Report
PP Protection Profile
RISC Reduced Instruction Set Computer
RPC Remote Procedure Call
SAR Security Assurance Requirement
SFR Security Functional Requirements
SGI Silicon Graphics, Inc
SMTP Simple Mail Transfer Protocol
SOF Strength of Function
ST Security Target
TCP Transmission Control Protocol
TOE Target of Evaluation
TSF TOE Security Functions
TSFI TSF Interface
UDP User Datagram Protocol
UID User Identifier
12
SGI IRIX Version 6.5.13
Validation Report
13 BIBLIOGRAPHY
[1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general
model, dated August 1999, Version 2.1.
[2] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional
requirements, dated August 1999, Version 2.1.
[3] Common Criteria for Information Technology Security Evaluation – Part 2: Annexes, dated August
1999, Version 2.1.
[4] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance
requirements, dated August 1999, Version 2.1.
[5] Common Evaluation Methodology for Information Technology Security – Part 1: Introduction and
general model, dated 1 November 1998, version 0.6.
[6] Common Evaluation Methodology for Information Technology Security – Part 2: Evaluation
Methodology, dated August 1999, version 1.0.
[7] NIAP Common Criteria Evaluation and Validation Scheme for IT Security, Guidance to Common
Criteria Testing Laboratories, Version 1.0, March 20, 2001.
[8] Evaluation Technical Report for the IRIX version 6.5.13, with Patches 4354, 4451, and 4452, and the
Trusted IRIX/CMW version 6.5.13, with Patches 4354, 4451, 4452, 4373, and 4473, Version 0.2, April
11, 2002.
[9] Silicon Graphics, Inc. IRIX Version 6.5.13, Security Target Version 1.9, May 1, 2002.
13
SGI IRIX Version 6.5.13
Validation Report
ANNEX A
Detailed Architectural Information
The services provided by the IRIX system are easiest to describe when divided into logical subsystems. Each subsystem
is responsible for policy enforcement or for maintaining information used by other subsystems for policy enforcement.
The following discussion provides a brief functional description of each major subsystem of IRIX. The discussion is
divided into three portions – hardware, kernel-mode, and user-mode.
The IRIX system executes instructions in two broad domains. Commands and applications execute in user-mode. In this
mode, the memory management system and hardware restrictions on instruction execution isolate processes from each
other, from operating system control data, and from direct hardware access. This establishes a strong separation of the
instruction streams and data contained in one process from those found in another process.
A thread within a share-group may initiate an operating system request from user-mode through the system call trap
mechanism. A system call trap is a software interrupt operation that causes a context switch from user-mode into kernel-
mode. In kernel-mode, the thread can only execute the kernel defined code sequence that follows from a system call.
This kernel code sequence, however, has unrestricted direct access to kernel control data and the hardware.
A.1 Hardware
The evaluated hardware of the IRIX workstation is the Origin200 equipped with one or two disk drives and a dumb
terminal connected to a serial interface. One or more workstations in a system may have tape drives and printers attached
to them. The evaluated configuration of the Origin 3000 server consists of various internal components that are divided
into separate units called "bricks". These bricks are housed in short or tall rack enclosures. The processor for the
Origin200 and Origin 3000 is a MIPS R12000 processor.
A.2 Kerne
l
-mode
A.2
.1 Process Management
The Process Management subsystem maintains all processes and share-groups under the control of the IRIX system. It
provides external operating system interfaces for creating a new process, changing its attributes, establishing a new
execution image, and destroying the process. The process management subsystem also provides the means for delivering
signals from one process to another and controlling the execution of a process from another process for the purpose of
debugging and similar functions.
A.2
.2 F
i
l
eManagement
The file management subsystem provides a name space and storage management mechanism for IRIX objects that
present an external interface based on the file abstraction. File management does not encompass operations on files
across a network because these involve more complex negotiation between the local and the remote IRIX system. For the
sake of clarity, this description segregates these responsibilities within the Network File System (NFS) subsystem. The
file management subsystem does, however, play a crucial role in the Network File System operational model.
A.2
.3 NFS
The NFS enables users to access files from remote hosts within the IRIX network using the same file system commands
used to access local files. NFS uses the Remote Procedure Call (RPC) protocol to transfer file system commands from
14
SGI IRIX Version 6.5.13
Validation Report
the requesting process (the client) to the host where file system is physically located (the server). The responses to these
requests are then sent back by RPC.
A.2
.4 Input
/Output
The Input/Output (I/O) subsystem allows a process to transfer data to and from peripheral devices such as disks, tape
drives, and printers. Each device in the system is represented by one or more device special files. IRIX uses the
information in the device special file to locate the appropriate device driver, which handles the device-specific requests.
A.2
.5 Memory Management
The memory management subsystem of IRIX provides a demand paged memory management model in which process
memory consists of regions that, in turn consist of pages. A process may contain several regions including, but not
limited to stack regions, data regions, executable text regions, memory mapped files, and shared data regions.
The memory management subsystem makes a strict distinction between a process, a share-group, and a share-group
member-thread. The memory management subsystem in IRIX exists to provide four functions:
• allocation, release, and sharing of memory associated with share-groups,
• mapping of entities such as files into memory addressable space for easier manipulation,
• transparent movement of data between high speed local memory and lower speed, higher capacity storage devices
(such as swap areas on disk), and
• enforcement of the boundaries between share-groups and between user-mode and kernel-mode processing.
A.2
.6 Audit
ing
The IRIX system provides an auditing mechanism that allows user level processes in the administrative or system
domain and kernel mechanisms to record security related activities by users and administrators. The audit mechanism
provides a means for capturing, buffering, writing to disk, and filtering audit trail information. It does not define the
contents of a given audit record. Only the subsystem in which a given event occurs knows the nature of any given
security related event. For this reason, subsystems hold the responsibility for the content of specific audit record types.
A.2
.7 In
terprocess Com municat
i
on
The Interprocess Communications (IPC) services offered by the kernel provide mechanisms for communication between
processes. IRIX supports AT&T System V, BSD, and IRIX -specific mechanisms. The IPC mechanisms allow
communication on local machines as well as across the network.
A.2
.8 Network
Included in the kernel is a set of network protocols. Users request services of trusted network applications to access and
utilize the resources of all workstations in the system. These trusted applications use the kernel network protocols for
their lower level communication services. IRIX implements Transmission Control Protocol (TCP), Internet Protocol
(IP), User Datagram Protocol (UDP), and Ethernet in the kernel.
A.3 User
-
mode
A.3
.1 UserNetwork Serv
ices
The provision of network services to users requires two processes: a client process, which is invoked by a user, and a
server process executing on a remote host. These client and server processes communicate with one another in the
Internet communication domain. Under this model, the server process waits for requests to perform some service, while
the client process asks the server to perform some service on its behalf. In the Internet domain, a server process generally
15
SGI IRIX Version 6.5.13
Validation Report
16
sets up a socket on which it "listens" for incoming requests to perform a service. The network services in the evaluated
configurations are; ftp, telnet, rlogin, rsh, echo, discard, chargen, daytime, and time.
A.3
.2 Identi
f
i
ca
t
ion and Authent
i
c
at
ion
IRIX identification and authentication is performed using a user name and password. In the password based
authentication model, the Interactive Login Services subsystem requires a user to specify a user name and a correct
password before creating an initial process for the user. The password verifies the authenticity of the user name. The user
name is then mapped to a user identifier (UID) for use in identifying the owner of the login session to the system. A user
failing to provide a suitable user name and password is not allowed to log into the IRIX system.
A.3
.3 Pr
in
t
er Subsys
tem
The Printing Services subsystem of IRIX provides controlled access to printing resources. It controls access to printers,
print queues, and jobs to avoid unauthorized interference with or observation of printing requests and resources.
A.3
.4 Batch Process
ing
The IRIX Batch Processing Services subsystem allows users to submit requests for either periodic or deferred
processing. There are three modes of batch processing supported:
1. Once as soon as possible but not as part of the user's current login session (submitted through batch(1)),
2. Once at a user specified time in the future (submitted through at(1)), and
3. Persistent and periodic, at times specified by the user (submitted through crontab(1)).
These commands accept user input and create entries in queues under the control of the Batch Processing Services
subsystem. A daemon called cron reads these queues and schedules jobs for execution. When a job's scheduled time of
execution arrives, cron establishes a session for that job and initiates processing.
A.3
.5 E
lec
t
ron
ic Mai
lSubsys
tem
IRIX uses the Internet Simple Mail Transfer Protocol (SMTP) for electronic mail. The sendmail process implements
SMTP. For mail with a remote destination, the client sendmail uses Internet domain sockets to communicate with the
remote sendmail process. The sendmail daemon listens on a known port and waits for a client to connect to the port and
begin transmitting a mail message.
A.3
.6 Trust
ed Com mands
IRIX provides a set of commands to be used for system administration. These commands can be used to manage all
aspects of the IRIX system, including commands to manage user accounts, audit configuration, device configuration, file
system backup, and audit event viewing. These commands are used to manage the system and are trusted to perform
correctly. The commands are documented in the administrator guide.