National Information Assurance Partnership ® TM Common Criteria Evaluation and Validation Scheme Validation Report Hewlett Packard Red Hat Enterprise Linux Version 4, Update 2 Report Number: CCEVS-VR-06-0020 Dated: 31 May 2006 Version: 1.1 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 ACKNOWLEDGEMENTS Validation Team The Aerospace Corporation Columbia, MD atsec Information Security Corporation Austin, TX Table of Contents 1. EXECUTIVE SUMMARY ........................................................................................................................................4 2. IDENTIFICATION....................................................................................................................................................4 3. SECURITY POLICY.................................................................................................................................................5 3.1. ACCESS CONTROL .................................................................................................................................................5 3.2. I&A.......................................................................................................................................................................6 3.3. AUDITING ..............................................................................................................................................................6 3.4. OBJECT REUSE ......................................................................................................................................................7 4. ASSUMPTIONS .........................................................................................................................................................7 4.1. USAGE ASSUMPTIONS ...........................................................................................................................................7 4.2. CLARIFICATION OF SCOPE .....................................................................................................................................8 5. ARCHITECTURAL INFORMATION ....................................................................................................................8 6. DOCUMENTATION .................................................................................................................................................9 7. IT PRODUCT TESTING...........................................................................................................................................9 7.1. SPONSOR TESTING.................................................................................................................................................9 7.2. EVALUATOR TESTING..........................................................................................................................................10 8. EVALUATED CONFIGURATION .......................................................................................................................10 9. RESULTS OF THE EVALUATION ......................................................................................................................11 10. VALIDATOR COMMENTS...............................................................................................................................11 11. SECURITY TARGET..........................................................................................................................................11 12. LIST OF ACRYONYMS .....................................................................................................................................12 13. BIBLIOGRAPHY.................................................................................................................................................13 3 1. EXECUTIVE SUMMARY This report documents the NIAP validators’ assessment of the evaluation of Hewlett Packard (HP) Red Hat Enterprise Linux (RHEL) Version 4, Update 2. It presents the evaluation results, their justifications, and the conformance results. This validation report is not an endorsement of the IT product by any agency of the U.S. Government and no warranty of the IT product is either expressed or implied. The evaluation was performed by the atsec Information Security Corporation, and was completed during February 2006. The information in this report is largely derived from the Evaluation Technical Report (ETR) and associated test report, both written by the CCTL. The evaluation determined the product to be Part 2 extended, Part 3 conformant, and to meet the requirements of EAL3 augmented by ALC_FLR.3. Additionally, the TOE was shown to satisfy the requirements of the Controlled Access Protection Profile (CAPP), Issue 1.d, 8 October 1999. Red Hat Enterprise Linux (RHEL) is a general-purpose, multi-user, multi-tasking operating system. As such, it provides a platform for a wide variety of arbitrary applications. Red Hat AS is available on a broad range of systems, from departmental servers to multi-processor enterprise servers; RHEL WS is available on workstations and small servers. The evaluation covers a potentially distributed, but closed network of HP (Pentium, Xeon, Itanium2, and Opteron based) servers and workstations running the evaluated configurations of the TOE. The validation team monitored the activities of the evaluation team, provided guidance on technical issues and evaluation processes, reviewed successive versions of the Security Target, reviewed selected evaluation evidence, reviewed test plans, reviewed intermediate evaluation results (i.e., the CEM work units), and reviewed successive versions of the evaluation technical report (ETR) and test report. The validation team determined that the evaluation team showed that the product satisfies all of the functional requirements and assurance requirements defined in the Security Target (ST) for a CAPP-compliant, EAL3 evaluation. Therefore, the validation team concludes that the CCTL findings are accurate, and the conclusions justified. 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 Assessment 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 desiring a security 4 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 Protection Profile to which the product is conformant; • The organizations and individuals participating in the evaluation. Table 1: Evaluation Identifiers Item Identifier Evaluation Scheme United States NIAP Common Criteria Evaluation and Validation Scheme Target of Evaluation HP Red Hat Enterprise Linux, Version 4 Update 2 Protection Profile Controlled Access Protection Profile (CAPP), Issue 1.d, 8 October 1999. Security Target Red Hat Enterprise Linux Version 4 Update 2 Security Target for CAPP Compliance; Version 2.4, 29 January 2006 Evaluation Technical Report Evaluation Technical Report a Target of Evaluation: Red Hat Enterprise Linux Version 4 Update 2 AS, and Red Hat Enterprise Linux Version 4 Update 2 WS. Version 1.0, 31 January 2006 Conformance Result CC V2.2, Part 2 extended, Part 3 conformant, EAL 3 augmented by ALC_FLR.3, and CAPP-compliant Sponsor Hewlett Packard Developer Hewlett Packard and Red Hat Evaluators atsec GmbH Validators The Aerospace Corporation 3. SECURITY POLICY 3.1. Access Control Red Hat Enterprise Linux implements Discretionary Access Control (DAC) through the use of standard UNIX permission bits and the POSIX standard Access Control Lists (ACLs). A Discretionary Access Control policy requires mechanisms whereby the access of users (i.e., subjects) to system resources and data (i.e., objects) can be controlled on the basis of user identity, role, and explicit permissions. Mechanisms that implement a DAC policy provide the capability for users to specify the how their personal data objects are to be shared. 5 Permission bits are associated with objects and specify the permissions (typically, READ, WRITE, EXECUTE) for a specific user, the user’s group affiliation, and all others (i.e., “world”). Access Control Lists provide the same functionality relative to granting specific permissions, but are considerably more flexible in that they can identify a number of group affiliations for a single user. The standard UNIX DAC mechanism is permission bits, as is the case with RHEL. However, RHEL implements ACLs as an extended permission mechanism, available at the discretion of the file owner; ACLs are supported only for file system objects.1 3.2. I&A Each user must have a unique identity (i.e., username plus password), and be authenticated prior to obtaining resources and services from the TOE. Note, however, that in a networked environment, user identities are unique to a server, and are neither known globally nor are universally unique. That is, each server maintains its own set of users and their associated passwords and attributes. A user that has access to more than one server on a network will have a different user identity, and possibly different attributes, on each server for which access is authorized. Users can change their own passwords. However, an administrator can define the following constraints for the authentication process: • Maximum duration of a password (i.e., time-to-live); • Minimum time allowed between password changes; • Minimum password length; • Number of days warnings are displayed prior to password expiration; • Allowed number of consecutive unsuccessful login attempts; • Disallowed passwords (i.e., the TOE retains a history of recently-used passwords to prevent users from cycling previously-used passwords). The proper parameters for each of these choices is defined for the evaluated configuration 3.3. Auditing The TOE audit mechanism allows the generation of audit records for security-related events, and allows the administrator to configure the audit mechanism to collect which events are to be captured and which users are to be audited; it is also possible for the administrator to identify specific users that are not to be audited. Each audit record contains event-specific information, and identifies whether the request that caused the event was successful or failed, and. An audit record consists of a standard header that includes the following information: 1 See Section 6.2.4 of the ST for a fuller discussion of the DAC mechanisms and the algorithm by which access determinations are made. 6 • A unique audit identifier; • The LoginID of the user who caused the audit record to be generated; • The Effective User ID of the user at the time the record was generated; • Date and time the audit record was generated; • Type of event. Audit records are stored in ASCII format, and can be searched through the use of the standard UNIX/LINUX grep tool. 3.4. Object Reuse Although the TOE supports several different types of objects, each is managed by the system such that no pre-existing content is provided to users to whom objects are allocated. That is, whenever an object (e.g., buffers, memory extents, disk space) is allocated to a user process, it is managed such that any data that had previously been in the object (i.e., from an earlier process) is unavailable to the new process. In short, memory pages are initialized to all zeroes when allocated to a process, IPC objects are also initialized to all zeroes, file system objects are created with no content (with the exception of directories and symbolic links).2 4. ASSUMPTIONS 4.1. Usage Assumptions Although there are several assumptions stated in the Security Target3 , the primary conditions are that: • The TOE is located within controlled facilities and is protected from unauthorized physical access; • TOE hardware and software are protected from unauthorized modification; • All authorized users possess authorization for at least some of the data managed on the TOE; • The TOE operates in a relatively benign environment; • Unencrypted communications paths, and communications paths within the controlled facility are protected from unauthorized physical access. 2 A more complete discussion of object reuse for each of the various object types is contained in Section 6.2.5 of the ST. 3 See section 3.4 of the ST 7 4.2. Clarification of Scope The TOE includes the hardware platform (see Section 8) and all the code that enforces the policies identified (see Section 3). TOE also includes secure communications functions; i.e., SSH V2 and SSL V3). The administrator tools are not considered to be part of the TSF. The administrator uses the commands that are provided by RHEL for system management; these are utilities that execute in untrusted user space, and are protected by the normal O/S mechanisms that prevent user processes from interfering with each other. Note that system management tools do not enforce TOE security policies, and that the TSF checks that the caller is authorized to invoke the requisite system calls and has the access rights to the objects being accessed. 5. ARCHITECTURAL INFORMATION The TOE is a multi-user, multi-tasking operating system which can support multiple users simultaneously. A fundamental protection mechanism is the memory management and virtual memory support provided by the hardware. This provides a domain (i.e., supervisor state) in which only the kernel executes. The TSF comprises two major components: kernel software and trusted processes. The kernel software executes in supervisor state, which is supported by the memory management mechanism in the hardware. The memory management mechanism insures that only kernel code can execute in the supervisor state (wherein all memory may be accessed), and also serves to protect the kernel code from external tampering. The kernel implements file and I/O services, which provides access to files and devices. The kernel also implements: • Named pipes • Unnamed pipes • Signals • Semaphores • Shared memory • Message queues • Internet domain sockets • Unix domain sockets. The trusted processes, which provide the remainder of the TSF, are referred to as “non-kernel TSF” services because they run in user state; they execute in the same hardware domain as user applications. These are protected from external tampering through the process management and memory virtualization mechanisms that implement per-process address spaces, that prevent processes from interfering with each other. They are also protected from unauthorized access by the access control mechanisms of the TSF. The primary non-kernel TSF services are: • Identification and authentication 8 • Network application layer services • Configuration and management commands requiring root privileges. 6. DOCUMENTATION The TOE is delivered with a combination of hardware and software specific documentation on CD. Hardware specific documentation varies with the model of the TOE and can be found at http://docs.hp.com/en/hw.html. The following software documentation is uniform across TOE hardware platforms: • Common Criteria EAL3+ Evaluated Configuration Guide for Red Hat Enterprise Linux on HP Hardware v1.16 2006-01-10; • Installation Guide for the x86, Itanium, and AMD64 Architectures v. RHEL4 2005-03-01; • Red Hat Enterprise Linux 4 Reference Guide v. RHEL4; • Red Hat Enterprise Linux 4 System Administration Guide v. RHEL4; • Red Hat Enterprise Linux 4 Security Guide v. RHEL4 2005-03-01. 7. IT PRODUCT TESTING 7.1. Sponsor Testing Tests are performed by both Red Hat and HP. However, only the tests performed by the sponsor (i.e., HP) were considered applicable to this evaluation. The majority of the tests cases are executed in the Linux Testing Project (LTP) environment. Additionally, the sponsor developed test cases for exercising the audit subsystem. These test cases were integrated into LTP environment and included in the test suite that was run by the sponsor. Additionally, the sponsor developed tests for the at command, and for exercising the ACL functionality. Manual tests were also developed and included in the test suite. Where necessary, the sponsor adopted existing test cases (i.e., changing some of the internal structure of the test cases) to more accurately reflect and exercise the current TOE. In the case of OpenSSL tests were developed based on the test suite from the OpenSSL developers. The sponsor provided mappings of each test case to the relevant TSF interface (TSFI), interface specification (i.e., FSP), and high-level design description (i.e., HLD). The evaluators identified a number of security-relevant internal interfaces (i.e., between subsystems and not reflected to the external, user interface) that were defined in the HLD, and ascertained that these were also exercised by the test suite. The evaluators ascertained that the testing was complete and fairly comprehensive, covering both explicit functionality as well as error conditions (e.g., invalid parameters, invalid credentials). 9 7.2. Evaluator Testing As an integral component of testing, the evaluator installed and configured the TOE on each of the platforms, and verified that the configuration for each test TOE was consistent with the ST. Because the majority of the sponsor’s tests can be run automatically the evaluators executed the entire automated test suite on all platforms. The sponsor’s test suite was judged to be quite complete and comprehensive, and thus the evaluator needed to design relatively few additional tests. However, some additional test cases were developed and executed for: • examining some of the TOE security functions in more detail than the sponsor-supplied test cases (e.g., Object Reuse, protection of audit records, password quality checks); • examining aspects not covered by developer testing (e.g., verification of ACL support in the archival tool, system reaction to absent security-relevant configuration options); • augmenting the testing of selected functions where the sponsor-supplied testing was deemed to be insufficiently broad. 8. EVALUATED CONFIGURATION4 The evaluated configurations are: • HP ProLiant DL systems, based on AMD Opteron, Intel Pentium and Intel Xeon processors (RHEL4 AS); • HP ProLiant BL systems, based on AMD Opteron, Intel Pentium and Intel Xeon processors (RHEL4 AS); • HP ProLiant ML systems, based on Intel Pentium and Xeon processors (RHEL4 AS); • HP Integrity Superdome systems, based on Intel Itanium2 processor (RHEL4 AS); • HP Integrity rx systems, based on Intel Itanium2 processor (RHEL4 AS); • HP Integrity cx systems, based on Intel Itanium2 processor (RHEL4 AS); • HP xw workstation systems, based on the Intel Xeon and Pentium 4 processors (RHEL4 WS); • HP Compaq dc systems, based on the Intel Pentium 4 processor (RHEL4 WS). Only the following subset of configurations were tested with the results being deemed sufficient to cover all configurations: • HP DL360 (Intel Xeon based SMP system) AS SMP, WS SMP and UP; • HP DL360 (Intel Xeon EM64T based SMP system) AS SMP and UP; 4 For more complete information on the evaluated configurations, see Section 2.4 of the Security Target. 10 • HP DL385 (AMD Opteron SMP system) SMP and UP; • HP DL385 (AMD Opteron dualcore SMP system) SMP and UP; • HP rx2600 (Intel Itanium2 SMP system) AS SMP; • HP Compaq dc7600 (Intel Pentium 4 UP system) WS UP. 9. RESULTS OF THE EVALUATION5 The evaluation team determined the product to be CC Part 2 extended, CC Part 3 conformant, CAPP conformant, and to meet the requirements of EAL 3 augmented by ALC_FLR.3. In short, the product satisfies the security technical requirements specified in HP Red Hat Enterprise Linux Version 4 Update 2 Security Target for CAPP Compliance, Version 2.4, 2006-01-29. 10. VALIDATOR COMMENTS There are no validator comments. 11. SECURITY TARGET The ST, HP Red Hat Enterprise Linux Version 4 Update 2 Security Target for CAPP Compliance, Version 2.4, 2006-01-29 is included here by reference. 5 The terminology in this section is defined in CC Interpretation 008, specifying new language for CC Part 1, section/Clause 5.4. 11 12. LIST OF ACRYONYMS CC Common Criteria CCEVS Common Criteria Evaluation and Validation Scheme CCTL Common Evaluation Testing Laboratory CEM Common Evaluation Methodology EAL Evaluation Assurance Level ETR Evaluation Technical Report NIAP National Information Assurance Partnership NIST National Institute of Standards & Technology NSA National Security Agency PP Protection Profile ST Security Target SMP Symmetric Multiprocessing TOE Target of Evaluation TSF TOE Security Function TSFI TOE Security Function Interface UP Uniprocessor 12 13 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] HP Red Hat Enterprise Linux Version 4 Update 2 Security Target for CAPP Compliance, Version 2.4, dated January 29 2006. [8] Evaluation Technical Report, for the Red Hat Enterprise Linux 4 Update 2 AS and WS, Version 1.0, January 31 2006. [9] Red Hat Enterprise Linux 4 Update 2 Tests: Coverage, Depth, and Functional Tests (Proprietary); Version 2.0, January 29 2006. [10] Evaluator Test Plan for RHEL4 Version 1.1, September 14 2005 (atsec Proprietary).