Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Version: 3.9 Last Update: 2007-05-31 Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 2 of 121 © HP, atsec 2004-2007 2007-05-31 atsec is a trademark of atsec GmbH HP and the HP logo are trademarks or registered trademarks of Hewlett-Packard Company in the United States, other countries, or both. IBM and IBM logo are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Red Hat and the Red Hat logo are registered trademarks of Red Hat, Inc. in the United States and other countries. Intel, Pentium, and Itanium are trademarks of Intel Corporation in the United States, other countries, or both. AMD and Opteron are trademarks of AMD Corporation in the United States, other countries, or both. Java and all Java-based products are trademarks of Sun Microsystems, Inc., in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group in the United States and other countries. This document is provided AS IS with no express or implied warranties. Use the information in this document at your own risk. This Security Target is derived from the “SuSE Linux Enterprise Server V 8 with Service Pack 3 Security Target with CAPP compliance”, version 2.7 sponsored by the IBM Corporation for the EAL3 evaluation. This original Security Target is copyrighted by IBM Corporation and atsec information security GmbH. This document may be reproduced or distributed in any form without prior permission provided the copyright notice is retained on all copies. Modified versions of this document may be freely distributed provided that they are clearly identified as such, and this copyright is included intact. Copyright of the original Security Target © 2004 by atsec GmbH, and IBM Corporation or its wholly owned subsidiaries. Copyright of the changes from the original Security Target © 2004, 2005, 2006, 2007 by atsec information security GmbH, atsec information security corporation, and HP Corporation or its wholly owned subsidiaries. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 3 of 121 © HP, atsec 2004-2007 2007-05-31 Document History Version Date Changes Summary Author 2.0 2005-09-16 n/a Initial version for RHEL4 U2 and NIAP scheme Klaus Weidner, atsec 2.1 2005-10-12 minor minor updates Klaus Weidner, atsec 2.2 2005-12-12 minor updated package list; minor updates based on evaluator’s feedback Klaus Weidner, atsec 2.3 2005-12-14 minor Updated audit events table Klaus Weidner, atsec 3.0 2006-03-09 major TOE is RHEL 5; Added LSPP and RBAC modes Gerald Krummeck, atsec 3.1 2006-03-22 major Update of Rationale, minor errors Gerald Krummeck, atsec 3.2 2006-04-20 minor Addressing comments from CB Gerald Krummeck, atsec 3.3 2006-05-31 minor Updated with hardware changes Robert Wenner, atsec 3.4 2006-08-28 minor Removed at package Robert Wenner, atsec 3.5 2006-09-26 minor Various updates Robert Wenner, atsec 3.6 2006-10-18 minor Updates due to HLD Wolfgang Mauerer, atsec 3.7 2007-02-06 minor Updates due to LLD, adding IPv6 Wolfgang Mauerer, atsec 3.8 2007-05-08 minor Updates after finishing of development of TOE Wolfgang Mauerer, atsec 3.9 2007-05-31 minor Add Client to platform list Wolfgang Mauerer, atsec Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 4 of 121 © HP, atsec 2004-2007 2007-05-31 Table of Content 1 Introduction..................................................................................................................................................................8 1.1 ST Identification ..................................................................................................................................................8 1.2 ST Overview ........................................................................................................................................................8 1.3 CC Conformance..................................................................................................................................................9 1.4 Strength of Function ............................................................................................................................................9 1.5 Structure...............................................................................................................................................................9 1.6 Terminology.........................................................................................................................................................9 2 TOE Description ........................................................................................................................................................11 2.1 Intended Method of Use.....................................................................................................................................11 2.2 Summary of Security Features...........................................................................................................................12 2.2.1 Identification and Authentication...............................................................................................................13 2.2.2 Audit ..........................................................................................................................................................13 2.2.3 Discretionary Access Control ....................................................................................................................13 2.2.4 Mandatory Access Control (LSPP/RBAC mode only) ..............................................................................13 2.2.5 Role-based Access Control (LSPP/RBAC mode only)..............................................................................13 2.2.6 Object Reuse ..............................................................................................................................................14 2.2.7 Security Management.................................................................................................................................14 2.2.8 Secure Communication ..............................................................................................................................14 2.2.9 TSF Protection ...........................................................................................................................................14 2.3 Software.............................................................................................................................................................14 2.4 Configurations....................................................................................................................................................21 2.4.1 File systems................................................................................................................................................22 2.4.2 TOE hardware............................................................................................................................................22 3 TOE Security Environment........................................................................................................................................24 3.1 Introduction........................................................................................................................................................24 3.2 Threats................................................................................................................................................................24 3.2.1 Threats countered by the TOE ...................................................................................................................24 3.2.2 Threats to be countered by measures within the TOE environment ..........................................................25 3.3 Organizational Security Policies........................................................................................................................25 3.4 Assumptions.......................................................................................................................................................26 3.4.1 Physical Aspects.........................................................................................................................................26 3.4.2 Personnel Aspects ......................................................................................................................................26 3.4.3 Procedural Assumptions.............................................................................................................................26 3.4.4 Connectivity Aspects .................................................................................................................................26 4 Security Objectives ....................................................................................................................................................28 4.1 Security Objectives for the TOE........................................................................................................................28 4.2 Security Objectives for the TOE Environment ..................................................................................................28 Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 5 of 121 © HP, atsec 2004-2007 2007-05-31 5 Security Requirements ...............................................................................................................................................30 5.1 TOE Security Functional Requirements ............................................................................................................30 5.1.1 Security Audit (FAU).................................................................................................................................30 5.1.2 Cryptographic Support (FCS) ....................................................................................................................37 5.1.3 User Data Protection (FDP) .......................................................................................................................39 5.1.4 Identification and Authentication (FIA).....................................................................................................46 5.1.5 Security Management (FMT).....................................................................................................................48 5.1.6 Protection of the TOE Security Functions (FPT).......................................................................................52 5.1.7 TOE Access (FTA) ....................................................................................................................................54 5.1.8 Trusted Path/Channels (FTP).....................................................................................................................54 5.1.9 Strength of Function...................................................................................................................................54 5.2 TOE Security Assurance Requirements.............................................................................................................54 5.3 Security Requirements for the IT Environment .................................................................................................55 5.4 Security Requirements for the Non-IT Environment.........................................................................................55 6 TOE Summary Specification .....................................................................................................................................56 6.1 Security Enforcing Components Overview .......................................................................................................56 6.1.1 Introduction................................................................................................................................................56 6.1.2 SELinux .....................................................................................................................................................56 6.1.3 Kernel Services ..........................................................................................................................................58 6.1.4 Non-Kernel TSF Services ..........................................................................................................................59 6.1.5 Network Services .......................................................................................................................................60 6.1.6 Security Policy Overview ..........................................................................................................................60 6.1.7 TSF Structure.............................................................................................................................................61 6.1.8 TSF Interfaces............................................................................................................................................61 6.1.9 Secure and Non-Secure States ...................................................................................................................62 6.2 Description of the Security Enforcing Functions...............................................................................................63 6.2.1 Introduction................................................................................................................................................63 6.2.2 Identification and Authentication (IA).......................................................................................................63 6.2.3 Audit (AU).................................................................................................................................................66 6.2.4 Discretionary Access Control (DA)...........................................................................................................68 6.2.5 Mandatory Access Control (MA) (LSPP/RBAC mode only)....................................................................74 6.2.6 Role-based Access Control (RBAC) (LSPP/RBAC mode only) ...............................................................76 6.2.7 Object Reuse (OR).....................................................................................................................................77 6.2.8 Security Management (SM) .......................................................................................................................78 6.2.9 Secure Communication (SC)......................................................................................................................81 6.2.10 TSF Protection (TP)...................................................................................................................................84 6.3 Supporting functions part of the TSF.................................................................................................................89 6.3.1 Processes executed by non-administrative users........................................................................................89 6.4 Assurance Measures...........................................................................................................................................90 Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 6 of 121 © HP, atsec 2004-2007 2007-05-31 6.5 TOE Security Functions requiring a Strength of Function ................................................................................91 7 Protection Profile Claims...........................................................................................................................................92 7.1 PP Reference......................................................................................................................................................92 7.2 PP Tailoring .......................................................................................................................................................92 7.2.1 Security Functional Requirements .............................................................................................................92 7.2.2 Threats, Policies, Assumptions and Objectives..........................................................................................92 7.2.3 Assurance Requirements............................................................................................................................93 8 Rationale ....................................................................................................................................................................94 8.1 Security Objectives Rationale............................................................................................................................94 8.1.1 Security Objectives Coverage....................................................................................................................94 8.1.2 Security Objectives Sufficiency.................................................................................................................95 8.2 Security Requirements Rationale.......................................................................................................................97 8.2.1 Internal Consistency of Requirements .......................................................................................................97 8.2.2 Security Requirements Coverage.............................................................................................................103 8.2.3 Security Requirements Dependency Analysis .........................................................................................106 8.2.4 Strength of function .................................................................................................................................108 8.2.5 Evaluation Assurance Level.....................................................................................................................108 8.3 TOE Summary Specification Rationale ...........................................................................................................109 8.3.1 Security Functions Justification ...............................................................................................................109 8.3.2 Assurance Measures Justification ............................................................................................................113 8.3.3 Strength of function .................................................................................................................................113 8.3.4 PP Threats ................................................................................................................................................114 8.3.5 PP Assumptions .......................................................................................................................................115 8.3.6 PP Objectives...........................................................................................................................................116 8.3.7 PP SFRs....................................................................................................................................................117 9 Abbreviations...........................................................................................................................................................121 Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 7 of 121 © HP, atsec 2004-2007 2007-05-31 References [CAPP] Controlled Access Protection Profile, Issue 1.d, 8 October 1999 [CC] Common Criteria for Information Technology Security Evaluation, Parts 1 to 3, CCMB-2005-08- 001 to CCMB-2005-08-003, Version 2.3, August 2005 [CEM] Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, CCMB-2005-08-004, Version 2.3, August 2005 [ECG] Evaluated Configuration Guide [GUIDE] ISO/IEC PDTR 15446 Title: Information technology – Security techniques – Guide for the production of protection profiles and security targets, ISO/IEC JTC 1/SC 27 N 2449, 2000-01-04 [IPSEC] “Security Architecture for the Internet Protocol”, ftp://ftp.rfc-editor.org/in-notes/rfc2401.txt [LSPP] Labeled Security Protection Profile, Version 1.b, 8 October 1999 [RBACPP] Role-Based Access Control Protection Profile, version 1.0, dated July 30, 1998 [SSH-AUTH] RFC 4252: The Secure Shell (SSH) Authentication Protocol, http://www.ietf.org/rfc/rfc4252.txt [SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.[SSLv3] The SSL Protocol Version 3.0; http://wp.netscape.com/eng/ssl3/drft302.txt [TARGET] Red Hat Enterprise Linux 5 Security Target (this document) [TLS-AES] RFC 3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS), http://www.ietf.org/rfc/rfc3268.txt [X.509] ITU-T RECOMMENDATION X.509 | ISO/IEC 9594-8: INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION - THE DIRECTORY: PUBLIC-KEY AND ATTRIBUTE CERTIFICATE FRAMEWORKS [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 8 of 121 © HP, atsec 2004-2007 2007-05-31 1 Introduction This is version 3.9 of the Security Target document for the evaluation of Red Hat Enterprise Linux Version 5 Server and Client (RHEL). There are no technical differences between the “Server” and “Client” version. RHEL in the evaluated configuration does not contain an X11 server and therefore no X11-based applications. The product is configured to be used as a server. The TOE includes the hardware and firmware used to run the software components. 1.1 ST Identification Title: Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance, Version 3.9 Keywords: Linux, Open Source, general-purpose operating system, POSIX, UNIX, security, multi-level security, role- based access control. This document is the security target for the CC evaluation of the Red Hat Enterprise Linux 5 operating system product, and is conformant to the Common Criteria for Information Technology Security Evaluation [CC] with extensions as defined in the Controlled Access Protection Profile [CAPP] and the Labeled Security Protection Profile [LSPP]. 1.2 ST Overview This security target documents the security characteristics of the Red Hat Enterprise Linux 5 operating system. Red Hat Enterprise Linux is a highly-configurable Linux-based operating system which has been developed to provide a good level of security as required in commercial environments and as a basis for secure computing, including • multi-level security based on sensitivity labels for objects and clearances for subjects, implementing the Bell/LaPadula model of mandatory access control • least-privilege operations using a fine-grained access control model and a rights and privilege management based on roles, • secure communications over public communication channels using encrypted tunnels. It also meets all of the requirements of • the Controlled Access Protection Profile [CAPP] developed by the Information Systems Security Organization within the National Security Agency to map the TCSEC C2 class of the U.S. Department of Defence (DoD) Trusted Computer System Evaluation Criteria (TCSEC) to the Common Criteria framework • the Labeled Security Protection Profile [LSPP] developed by the Information Systems Security Organization within the National Security Agency to map the TCSEC B1 class of the U.S. Department of Defence (DoD) Trusted Computer System Evaluation Criteria (TCSEC) to the Common Criteria framework • the Role-Based Access Control Protection Profile [RBACPP] developed by NIST and CygnaCom Solutions. This Security Target therefore claims full compliance with the requirements of these Protection Profiles and also includes additional functional and assurance packages beyond those required by CAPP, LSPP and RBAC. Several servers running Red Hat Enterprise Linux can be connected to form a networked system. The communication aspects within Red Hat Enterprise Linux used for this connection are also part of the evaluation. Communication links can be protected against loss of confidentiality and integrity by security functions of the TOE based on cryptographic protection mechanisms. This evaluation focuses on the use of the TOE as a server or a network of servers. Therefore a graphical user interface has not been included as part of the evaluation. In addition the evaluation assumes the operation of the network of servers in a non-hostile environment. This Security Target covers two modes of operation of the TOE: In LSPP/RBAC mode, the TOE operates with all multi-level security and RBAC features enabled, thus fulfilling the requirements of [LSPP], [CAPP], and [RBACPP]. In CAPP mode, the TOE operates in a “standard” mode without these security extensions enabled, still meeting the requirements of [CAPP]. In CAPP mode, SELinux is either turned off or can be used with the targeted policy as Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 9 of 121 © HP, atsec 2004-2007 2007-05-31 SELinux only has additional restrictions compared to CAPP. However, the MLS policy should not be used as it interferes with the UID 0 mechanics that are important to CAPP. 1.3 CC Conformance This ST is CC Part 2 extended and Part 3 conformant, with a claimed Evaluation Assurance Level of EAL4 augmented by ALC_FLR.3. The extensions to part 2 of the Common Criteria are those introduced by the Controlled Access Protection Profile [CAPP], the Labeled Security Protection Profile [LSPP] and the Role-Based Access Control Protection Profile [RBACPP]. 1.4 Strength of Function The claimed strength of function for this TOE is: SOF-medium. 1.5 Structure The structure of this document is as defined by [CC] Part 1 Annex C. • Section 2 is the TOE Description. • Section 3 provides the statement of TOE security environment. • Section 4 provides the statement of security objectives. • Section 5 provides the statement of IT security requirements. • Section 6 provides the TOE summary specification, which includes the detailed specification of the IT Security Functions. • Section 7 provides the Protection Profile claim • Section 8 provides the rationale for the security objectives, security requirements and the TOE summary specification. 1.6 Terminology This section contains definitions of technical terms that are used with a meaning specific to this document. Terms defined in the [CC] are not reiterated here, unless stated otherwise. Authorized user: This term refers to a user who has been properly identified and authenticated. These users are considered to be legitimate users of the TOE. Administrative User: This term refers to an administrator of a RHEL. Administrators are users having privileges to execute special commands interfering with the security functionality or they can modify the configuration which affects the security functionality. In CAPP mode, the only administrative user is root (UID 0). In LSPP/RBAC mode, the role functionality allows different users having different administrative privileges. Authorized administrator: An authorized administrator is an authorized user who has been granted the authority to manage the TOE. These users are expected to use this authority only in the manner prescribed by the guidance given them. For the purpose of this ST, “authorized administrators” and “administrative users” are synonym terms. Active Role Set (ARS): This is the subset of the set of authorized roles for a user that has actually been activated for the user in a particular user session. The total set of access rights (privileges) available to a user in a session is the sum of the access rights directly assigned to each member of ARS together with the privileges inherited by each member of ARS through roles assigned to it. Authentication data: This includes the password for each user of the product. Authentication mechanisms using other authentication data than a password are not supported in the evaluated configuration. Authorized Roles for the User: This is the set of roles directly assigned to the user by the RBAC Administrator together with the set of roles contained in those roles (due to role to role assignments) Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 10 of 121 © HP, atsec 2004-2007 2007-05-31 Data: arbitrary bit sequences in computer memory or on storage media. Default Active Role Set (DARS): Instead of forcing the user to build an Active Role Set (ARS) during every user session, the RBAC administrator provides a default set of roles (from the list of authorized roles for the user). The composition of DARS determines the initial available access rights for the user at the start of the session. In other words, DARS is the ARS at the time of session creation. In many software environment the user may be able to change the composition of this initial ARS (i.e. DARS) during the course of the user session. Information: any data held within a server, including data in transit between servers. Named Object: In Red Hat Enterprise Linux, those objects that are subject to access control, which are file system objects and IPC objects. Object Owner: The user who creates a named object becomes the object owner by default. In some environments, the object owner can be changed by the system administrator. The object owner has generally all discretionary access rights on the object and the power to grant discretionary access rights on the objects he/she owns to roles and other users. Object: In Red Hat Enterprise Linux, objects belong to one of three categories: file system objects, IPC objects, and memory objects. Privilege Set for a Role: The total set of system privileges and access rights on various objects granted to a role. Product: The term product is used to define software components that comprise the Red Hat Enterprise Linux system. RHEL: This term serves as an abbreviation for "Red Hat Enterprise Linux", which is the Target of this evaluation. Role: A role represents a set of actions that an authorized user, upon assuming the role, can perform. In this TOE only the roles of administrative user and normal user are supported. Security Attributes: As defined by functional requirement FIA_ATD.1, the term ‘security attributes’ includes the following as a minimum: user identifier; group memberships; user authentication data. SELinux: SELinux is a component of the Linux operating system implementing the MLS and role based access control checks. It is implemented in kernel space with supporting user space configuration tools. The kernel component utilizes the Linux Security Module framework to allow its functionality being disabled without impacting the rest of the kernel (SELinux is optional in CAPP mode). Subject: There are two classes of subjects in Red Hat Enterprise Linux: • untrusted internal subject - this is a Red Hat Enterprise Linux process running on behalf of some user, running outside of the TSF (for example, with no privileges). • trusted internal subject - this is a Red Hat Enterprise Linux process running as part of the TSF. Examples are service daemons and the process implementing the identification and authentication of users. System: Includes the hardware, software and firmware components of the Red Hat Enterprise Linux product which are connected/networked together and configured to form a usable system. Target of Evaluation (TOE): The TOE is defined as the Red Hat Enterprise Linux operating system, running and tested on the hardware and firmware specified in this Security Target. The BootPROM firmware as well as the hardware form part of the TOE as required by the NIAP interpretation of CAPP. User: Any individual/person who has a unique user identifier and who interacts with the Red Hat Enterprise Linux product. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 11 of 121 © HP, atsec 2004-2007 2007-05-31 2 TOE Description The target of evaluation (TOE) is the operating system Red Hat Enterprise Linux 5. Red Hat Enterprise Linux is a general purpose, multi-user, multi-tasking Linux based operating system. It provides a platform for a variety of applications in the governmental and commercial environment. Red Hat Enterprise Linux is available on a broad range of computer systems, ranging from departmental servers to multi-processor enterprise servers. The Red Hat Enterprise Linux evaluation covers a potentially distributed, but closed network of HP (Itanium2, Pentium, Xeon, and Opteron based) servers running the evaluated version of Red Hat Enterprise Linux. The hardware platforms selected for the evaluation consist of machines which are available when the evaluation has completed and to remain available for a substantial period of time afterwards. The TOE Security Functions (TSF) consist of functions of Red Hat Enterprise Linux that run in kernel mode plus some trusted processes. These are the functions that enforce the security policy as defined in this Security Target. Tools and commands executed in user mode that are used by an administrative user need also to be trusted to manage the system in a secure way. But as with other operating system evaluations they are not considered to be part of this TSF. The hardware and the BootProm firmware are considered to be part of the TOE as required by the deliberate NIAP interpretation of CAPP and LSPP. The TOE includes installation from CDROM/DVDROM and from a local hard disk partition. The TOE includes standard networking applications, such as ftp, ssl and ssh. xinetd is used to protect network applications which might otherwise have security exposures. The TOE provides means to encrypt communication channels. IPSec allows transporting sensitivity labels, thus enabling to enforce mandatory access controls between connected systems providing the same implementation. System administration tools include the standard Linux commands. A graphical user interface for system administration or any other operation is not included in the evaluated configuration. The TOE environment also includes applications that are not evaluated, but are used as unprivileged tools to access public system services. For example a HTTP server using a port above 1024 (e. g. on port 8080) may be used as a normal application running without root privileges on top of the TOE. The Evaluated Configuration Guide provides guidance how to set up an HTTP server on the TOE in a secure way. In its evaluated configuration, the TOE allows two modes of operation: LSPP/RBAC-compliant and CAPP-compliant. In both modes, the same software elements are used. While the CAPP-compliant mode is compliant to [CAPP] only, LSPP-compliant mode provides compliance to [LSPP], [RBACPP] and [CAPP]. 2.1 Intended Method of Use The TOE is a Linux-based multi-user multi-tasking operating system. The TOE may provide services to several users at the same time. After successful login, the users have access to a general computing environment, allowing the start-up of user applications, issuing user commands at shell level, creating and accessing files. The TOE provides adequate mechanisms to separate the users and protect their data. Privileged commands are restricted to administrative users. The TOE uses a role-based model of normal (unprivileged) users and administrative users that have the capability to use certain privileges depending on their assigned role. The granularity of privilege assignments to administrative users varies between the modes of operation: ƒ In CAPP mode, the system allocates all privileges to the user ID 0 (initially allocated to the “root” account). A user allowed to switch to this identity (and thereby become an administrative user) can therefore exercise all these privileges. In addition, certain privileges (such as setting access rights for a file) are also available to the object owner. ƒ In LSPP/RBAC mode, privileges are assigned to certain roles. Users allowed to assume such a role are restricted to the privileges allocated to this role. Therefore, the power of the superuser can be broken up and assigned to different users, thus avoiding the concentration of all power in the hand of one administrator. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 12 of 121 © HP, atsec 2004-2007 2007-05-31 The TOE is intended to operate in a networked environment with other instantiations of the TOE as well as other well- behaved client systems operating within the same management domain. All those systems need to be configured in accordance with a defined common security policy. The TOE permits one or more processors and attached peripheral and storage devices to be used by multiple users to perform a variety of functions requiring controlled shared access to the data stored on the system. Such installations are typical for workgroup or enterprise computing systems accessed by users local to, or with otherwise protected access to, the computer system. It is assumed that responsibility for the safeguarding of the data protected by the TOE can be delegated to the TOE users for the purpose of discretionary access controls to user-owned data. All data is under the control of the TOE. The data is stored in named objects, and the TOE can associate with each named object a description of the access rights to that object. All individual users are assigned a unique user identifier within the single host system that forms the TOE. This user identifier is used as the basis for discretionary access control decisions. The TOE authenticates the claimed identity of the user before allowing the user to perform any further actions. The TOE enforces controls such that access to data objects can only take place in accordance with the access restrictions placed on that object by its owner or administrative users. Ownership of named objects may be transferred under the control of the access control policy. Access rights (e.g. read, write, execute) can be assigned to data objects with respect to subjects (users). Once a subject is granted access to an object, the content of that object may be freely used to influence other objects accessible to this subject. Red Hat Enterprise Linux has significant security extensions compared to standard UNIX systems: • SELinux and LSM, providing a framework for domain-type access control, with role-based access control • Access Control Lists for fine-grained access controls to persistent objects, allowing controls beyond the capabiligties of the traditional UNIX access control mechanism based on permission bits (to which the implementation is compatible) • A Journaling File System • Integrated authentication framework (PAM). The combination of PAM modules described in section 6.2.2 allows to enforce password quality metrics, to restrict logins from certain accounts by their point of entry, and to block logins from accounts after a number of consecutive failed logins. • A dedicated auditing subsystem. This auditing subsystem allows for the auditing of security critical events and provides tools for the administrative user to configure the audit subsystem and evaluate the audit records. • Basic check functions for the TOE’s underlying abstract machine. They allow an administrative user to check on demand if the basic security functions of the hardware the TOE relies upon are provided correctly. 2.2 Summary of Security Features The primary security features of the product are: • Identification and Authentication • Audit • Discretionary Access Control • Mandatory Access Control (LSPP/RBAC mode only) • Role-based Access Control (LSPP/RBAC mode only) • Object reuse functionality • Security Management • Secure Communication • TSF Protection. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 13 of 121 © HP, atsec 2004-2007 2007-05-31 These primary security features are supported by domain separation and reference mediation, which ensure that the features are always invoked and cannot be bypassed. 2.2.1 Identification and Authentication Red Hat Enterprise Linux provides identification and authentication using pluggable authentication modules (PAM) based upon user passwords. The quality of the passwords used can be enforced through configuration options controlled by Red Hat Enterprise Linux. Other authentication methods (e. g. Kerberos authentication, token based authentication) that are supported by Red Hat Enterprise Linux as pluggable authentication modules are not part of the evaluated configuration. Functions to ensure medium password strength and limit the use of the su command and restrict administrator login to specific terminals are also included. 2.2.2 Audit The TOE provides an audit capability that allows generating audit records for security critical events. The administrative user can select which events are audited and for which users auditing is active. A list of events that can be audited is defined in chapter 5 and 6. The TOE provides tools that help the administrative user extract specific types of audit events, audit events for specific users, audit events related to specific file system objects or audit events within a specific time frame from the overall audit records collected by the TOE. The audit records are stored in ASCII text, no conversion of the information into human readable form is necessary. The audit function detects when the capacity of the audit trail exceeds configurable thresholds, and the system administrator can define actions to be taken when the threshold is exceeded. The possible actions include generating a syslog message to inform the administrator, switching the system to single user mode (this prevents all user-initiated auditable actions), or halting the system. The audit function also ensures that no audit records get lost due to exhaustion of the internal audit buffers. Processes that try to create an audit record while the internal audit buffers are full will be halted until the required resources are available again. In the unlikely case of unrecoverable resource exhaustion, the kernel audit component initiates a kernel panic to prevent all further auditable events. 2.2.3 Discretionary Access Control Discretionary Access Control (DAC) restricts access to file system objects based on Access Control Lists (ACLs) that include the standard UNIX permissions for user, group and others. Access control mechanisms also protect IPC objects from unauthorized access. Red Hat Enterprise Linux includes the ext3 file system, which supports POSIX ACLs. This allows defining access rights to files within this type of file system down to the granularity of a single user. 2.2.4 Mandatory Access Control (LSPP/RBAC mode only) Red Hat Enterprise Linux provides mandatory access control (MAC) in LSPP mode, which imposes access restrictions to information based on security classification. Users and resources can have a sensitivity label associated. Sensitivity labels contain a hierarchical classification (security level), which specify the sensitivity (for example: public, internal use, or secret), and zero or more non-hierarchical security categories. The access control enforced by the TOE ensures that users can only read labeled information if their sensitivity labels dominate the information’s label, and that they can only write to labeled information containers if the container’s label dominates the subject’s, thus implementing the Bell-LaPadula model of information flow control. 2.2.5 Role-based Access Control (LSPP/RBAC mode only) Red Hat Enterprise Linux supports the concept of Roles, allowing administrative powers to be broken into many discrete Roles. This removes the requirement of one superuser (root or only one system-administrator) to administer the TOE and introduces a separation of duty. A Role combines a set of privileges to accomplish distinguished Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 14 of 121 © HP, atsec 2004-2007 2007-05-31 administrative tasks, thus allowing the administrative functionality to be distributed and hence diluted amongst the Roles, to reduce the impact of any misuse of a Role. Roles are also used in combination with the domain/type enforcement do define policies against such roles rather than for each individual separately. 2.2.6 Object Reuse File system objects as well as memory and IPC objects will be cleared before they can be reused by a process belonging to a different user. 2.2.7 Security Management The management of the security critical parameters of the TOE is performed by administrative users. A set of commands that require privileges are used for system management; they require users to possess appropriate privileges to execute them. Security parameters are stored in specific files that are protected by the access control mechanisms of the TOE against unauthorized access by users that are not administrative users. 2.2.8 Secure Communication The TOE supports secure communication with other systems via the SSH v2, SSL v3, CIPSO, and IPSec protocols. Communication via those protocols is protected against unauthorized disclosure and modification via cryptographic mechanisms. The TOE also allows for secure authentication of the communicating parties using the SSL v3 protocol with client and server authentication. This allows establishing a secure communication channel between different machines running the TOE even over an insecure network. The SSL v3, CIPSO, and IPSec protocols can be used to tunnel otherwise unprotected protocols in a way that allows an application to secure its TCP based communication with other servers (provided the protocol uses a single TCP port). 2.2.9 TSF Protection While in operation, the kernel software and data are protected by the hardware memory protection mechanisms. The memory and process management components of the kernel ensure a user process cannot access kernel storage or storage belonging to other processes. Non-kernel TSF software and data are protected by DAC, MAC and process isolation mechanisms. In the evaluated configuration, the reserved user ID root owns the directories and files that define the TSF configuration. In general, files and directories containing internal TSF data (e.g., configuration files, batch job queues) are also protected from reading by DAC and MAC permissions. The TOE including the hardware and firmware components are required to be physically protected from unauthorized access. The TOE contains two types of hardware components: those directly accessible to user processes (a subset of the CPU registers and memory); and those that the kernel protects from direct access by user programs. A user process may execute unprivileged instructions and read or write to memory and processor registers within the bounds defined by the kernel for the user process, those types of access are not mediated by the kernel. All other types of access to hardware resources by user processes can only be performed by requests (in the form of system calls) to the kernel. The TOE provides a tool that allows an administrative user to check the correct operation of the underlying hardware. This tool performs tests to check the system memory, the memory protection features of the underlying processor and the correct separation between user and supervisor state. 2.3 Software The Target of Evaluation is based on the following system software: Red Hat Enterprise Linux 5 The TOE and its documentation are supplied on CD-ROM and via the Red Hat Network Internet delivery method. With the TOE software, the user receives the Evaluated Configuration Guide and scripts that can be used for the secure installation process. The user needs to verify the integrity and authenticity of those packages using the standard package verification procedure as described in the manuals distributed with the product. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 15 of 121 © HP, atsec 2004-2007 2007-05-31 The following list of packages makes up the TOE in the evaluated configuration. This includes packages that contribute to the TSF as well as packages that contain untrusted user programs from the distribution. Note that additional untrusted user programs may be installed and used as long as they are ƒ not SUID or SGID to root; ƒ (LSPP/RBAC mode only) not bearing additional privileges or security contexts interfering with existing security contexts. The list of packages shown in Table 2-1 is identical for the LSPP/RBAC and CAPP modes of operation. The list contains the packages with their version numbers for each architecture. Table 2-1: List of TOE packages rpms-i386.txt rpms-ia64.txt rpms-x86_64.txt Deployment_Guide-en-US 5.0.0.19 5.0.0.19 5.0.0.19 GConf2 2.14.0.9.el5 2.14.0.9.el5 2.14.0.9.el5 MAKEDEV 3.23.1.2 3.23.1.2 3.23.1.2 NetworkManager 0.6.4.6.el5 0.6.4.6.el5 0.6.4.6.el5 ORBit2 2.14.3.4.el5 2.14.3.4.el5 2.14.3.4.el5 OpenIPMI 2.0.6.5.el5.3 2.0.6.5.el5.3 2.0.6.5.el5.3 OpenIPMI-libs 2.0.6.5.el5.3 2.0.6.5.el5.3 2.0.6.5.el5.3 SysVinit 2.86.14 2.86.14 2.86.14 acl 2.2.39.2.1.el5 2.2.39.2.1.el5 2.2.39.2.1.el5 acpid 1.0.4.5 1.0.4.5 1.0.4.5 aide 0.12.9.el5 0.12.9.el5 0.12.9.el5 amtu 1.0.4.4 1.0.4.4 1.0.4.4 anacron 2.3.45.el5 2.3.45.el5 2.3.45.el5 apmd 3.2.2.5 - - aspell 0.60.3.7.1 0.60.3.7.1 0.60.3.7.1 aspell#2 - - 0.60.3.7.1 aspell-en 6.0.2.1 6.0.2.1 6.0.2.1 at 3.1.8.82.fc6 3.1.8.82.fc6 3.1.8.82.fc6 atk 1.12.2.1.fc6 1.12.2.1.fc6 1.12.2.1.fc6 attr 2.4.32.1.1 2.4.32.1.1 2.4.32.1.1 audit 1.3.1.6.el5 1.3.1.6.el5 1.3.1.6.el5 audit-libs 1.3.1.6.el5 1.3.1.6.el5 1.3.1.6.el5 audit-libs#2 - - 1.3.1.6.el5 audit-libs-devel 1.3.1.6.el5 1.3.1.6.el5 1.3.1.6.el5 audit-libs-devel#2 - - 1.3.1.6.el5 audit-libs-python 1.3.1.6.el5 1.3.1.6.el5 1.3.1.6.el5 authconfig 5.3.12.2.el5 5.3.12.2.el5 5.3.12.2.el5 autoconf 2.59.12 2.59.12 2.59.12 autofs 5.0.1.0.rc2.42 5.0.1.0.rc2.42 5.0.1.0.rc2.42 automake 1.9.6.2.1 1.9.6.2.1 1.9.6.2.1 basesystem 8.0.5.1.1 8.0.5.1.1 8.0.5.1.1 bash 3.1.16.1 3.1.16.1 3.1.16.1 bc 1.06.21 1.06.21 1.06.21 beecrypt 4.1.2.10.1.1 4.1.2.10.1.1 4.1.2.10.1.1 bind-libs 9.3.3.7.el5 9.3.3.7.el5 9.3.3.7.el5 bind-utils 9.3.3.7.el5 9.3.3.7.el5 9.3.3.7.el5 binutils 2.17.50.0.6.2.el5 2.17.50.0.6.2.el5 2.17.50.0.6.2.el5 bison 2.3.2.1 2.3.2.1 2.3.2.1 bluez-gnome 0.5.5.fc6 0.5.5.fc6 0.5.5.fc6 bluez-libs 3.7.1 3.7.1 3.7.1 bluez-utils 3.7.2 3.7.2 3.7.2 bzip2 1.0.3.3 1.0.3.3 1.0.3.3 bzip2-libs 1.0.3.3 1.0.3.3 1.0.3.3 cairo 1.2.4.1.fc6 1.2.4.1.fc6 1.2.4.1.fc6 capp-lspp-eal4-config-hp 0.64.4 0.64.4 0.64.4 ccid 1.0.1.6.el5 1.0.1.6.el5 1.0.1.6.el5 checkpolicy 1.33.1.2.el5 1.33.1.2.el5 1.33.1.2.el5 chkconfig 1.3.30.1.1 1.3.30.1.1 1.3.30.1.1 chkfontpath 1.10.1.1.1 1.10.1.1.1 1.10.1.1.1 conman 0.1.9.2.4.el5 0.1.9.2.4.el5 0.1.9.2.4.el5 coolkey 1.0.1.16.el5 1.0.1.16.el5 1.0.1.16.el5 coolkey#2 - - 1.0.1.16.el5 coreutils 5.97.12.1.el5 5.97.12.1.el5 5.97.12.1.el5 cpio 2.6.20 2.6.20 2.6.20 cpp 4.1.1.52.el5 4.1.1.52.el5 4.1.1.52.el5 cpuspeed 1.2.1.1.45.el5 1.2.1.1.45.el5 1.2.1.1.45.el5 cracklib 2.8.9.3.1 2.8.9.3.1 2.8.9.3.1 cracklib#2 - - 2.8.9.3.1 cracklib-dicts 2.8.9.3.1 2.8.9.3.1 2.8.9.3.1 crash 4.0.3.14 4.0.3.14 4.0.3.14 Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 16 of 121 © HP, atsec 2004-2007 2007-05-31 crontabs 1.10.8 1.10.8 1.10.8 cryptsetup-luks 1.0.3.2.2.el5 1.0.3.2.2.el5 1.0.3.2.2.el5 cryptsetup-luks#2 - - 1.0.3.2.2.el5 cups 1.2.4.11.8.el5 1.2.4.11.8.el5 1.2.4.11.8.el5 cups-libs 1.2.4.11.8.el5 1.2.4.11.8.el5 1.2.4.11.8.el5 cups-libs#2 - - 1.2.4.11.8.el5 curl 7.15.5.2.el5 7.15.5.2.el5 7.15.5.2.el5 cvs 1.11.22.5.el5 1.11.22.5.el5 1.11.22.5.el5 cyrus-sasl 2.1.22.4 2.1.22.4 2.1.22.4 cyrus-sasl-devel 2.1.22.4 2.1.22.4 2.1.22.4 cyrus-sasl-lib 2.1.22.4 2.1.22.4 2.1.22.4 cyrus-sasl-lib#2 - - 2.1.22.4 cyrus-sasl-plain 2.1.22.4 2.1.22.4 2.1.22.4 cyrus-sasl-plain#2 - - 2.1.22.4 db4 4.3.29.9.fc6 4.3.29.9.fc6 4.3.29.9.fc6 db4#2 - - 4.3.29.9.fc6 dbus 1.0.0.6.el5 1.0.0.6.el5 1.0.0.6.el5 dbus-glib 0.70.5 0.70.5 0.70.5 dbus-python 0.70.7.el5 0.70.7.el5 0.70.7.el5 desktop-file-utils 0.10.7 0.10.7 0.10.7 device-mapper 1.02.13.1.el5 1.02.13.1.el5 1.02.13.1.el5 device-mapper#2 - - 1.02.13.1.el5 dhcdbd 2.2.1.el5 2.2.1.el5 2.2.1.el5 dhclient 3.0.5.3.el5 3.0.5.3.el5 3.0.5.3.el5 dhcpv6_client 0.10.33.el5 0.10.33.el5 0.10.33.el5 diffutils 2.8.1.15.2.2 2.8.1.15.2.2 2.8.1.15.2.2 dmidecode 2.7.1.28.2.el5 - 2.7.1.28.2.el5 dmraid 1.0.0.rc13.2.el5 1.0.0.rc13.2.el5 1.0.0.rc13.2.el5 dos2unix 3.1.27.1 3.1.27.1 3.1.27.1 dosfstools 2.11.6.2.el5 2.11.6.2.el5 2.11.6.2.el5 dump 0.4b41.2.fc6 0.4b41.2.fc6 0.4b41.2.fc6 e2fsprogs 1.39.8.el5 1.39.8.el5 1.39.8.el5 e2fsprogs-devel 1.39.8.el5 1.39.8.el5 1.39.8.el5 e2fsprogs-libs 1.39.8.el5 1.39.8.el5 1.39.8.el5 e2fsprogs-libs#2 - - 1.39.8.el5 ed 0.2.38.2.2 0.2.38.2.2 0.2.38.2.2 eject 2.1.5.4.2.el5 2.1.5.4.2.el5 2.1.5.4.2.el5 elfutils 0.125.3.el5 0.125.3.el5 0.125.3.el5 elfutils-libelf 0.125.3.el5 0.125.3.el5 0.125.3.el5 elfutils-libs 0.125.3.el5 0.125.3.el5 0.125.3.el5 elilo - 3.6.2 - elinks 0.11.1.5.1.el5 0.11.1.5.1.el5 0.11.1.5.1.el5 ethtool 5.1.el5 5.1.el5 5.1.el5 expat 1.95.8.8.2.1 1.95.8.8.2.1 1.95.8.8.2.1 expat#2 - - 1.95.8.8.2.1 expect 5.43.0.5.1 5.43.0.5.1 5.43.0.5.1 expect#2 - - 5.43.0.5.1 expect-devel 5.43.0.5.1 5.43.0.5.1 5.43.0.5.1 expect-devel#2 - - 5.43.0.5.1 fbset 2.1.22 2.1.22 2.1.22 file 4.17.8 4.17.8 4.17.8 filesystem 2.4.0.1 2.4.0.1 2.4.0.1 findutils 4.2.27.4.1 4.2.27.4.1 4.2.27.4.1 finger 0.17.32.2.1.1 0.17.32.2.1.1 0.17.32.2.1.1 firstboot-tui 1.4.27.2.1.el5 1.4.27.2.1.el5 1.4.27.2.1.el5 flex 2.5.4a.41.fc6 2.5.4a.41.fc6 2.5.4a.41.fc6 fontconfig 2.4.1.6.el5 2.4.1.6.el5 2.4.1.6.el5 freetype 2.2.1.16.el5 2.2.1.16.el5 2.2.1.16.el5 ftp 0.17.33.fc6 0.17.33.fc6 0.17.33.fc6 gawk 3.1.5.14.el5 3.1.5.14.el5 3.1.5.14.el5 gcc 4.1.1.52.el5 4.1.1.52.el5 4.1.1.52.el5 gcc-c++ 4.1.1.52.el5 4.1.1.52.el5 4.1.1.52.el5 gdbm 1.8.0.26.2.1 1.8.0.26.2.1 1.8.0.26.2.1 gettext 0.14.6.4.el5 0.14.6.4.el5 0.14.6.4.el5 ghostscript 8.15.2.9.1.el5 8.15.2.9.1.el5 8.15.2.9.1.el5 ghostscript#2 - - 8.15.2.9.1.el5 glib2 2.12.3.2.fc6 2.12.3.2.fc6 2.12.3.2.fc6 glib2-devel 2.12.3.2.fc6 2.12.3.2.fc6 2.12.3.2.fc6 glibc 2.5.12 2.5.12 2.5.12 glibc#2 - - 2.5.12 glibc-common 2.5.12 2.5.12 2.5.12 glibc-devel 2.5.12 2.5.12 2.5.12 glibc-devel#2 - - 2.5.12 glibc-headers 2.5.12 2.5.12 2.5.12 gnu-efi 3.0c.1.1 3.0c.1.1 - gnupg 1.4.5.12 1.4.5.12 1.4.5.12 gnutls 1.4.1.2 1.4.1.2 1.4.1.2 gnutls#2 - - 1.4.1.2 Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 17 of 121 © HP, atsec 2004-2007 2007-05-31 gpg-pubkey 37017186.45761324 37017186.45761324 37017186.45761324 gpm 1.20.1.74.1 1.20.1.74.1 1.20.1.74.1 gpm#2 - - 1.20.1.74.1 grep 2.5.1.54.2.el5 2.5.1.54.2.el5 2.5.1.54.2.el5 groff 1.18.1.1.11.1 1.18.1.1.11.1 1.18.1.1.11.1 grub 0.97.13 - 0.97.13 gtk2 2.10.4.16.el5 2.10.4.16.el5 2.10.4.16.el5 gzip 1.3.5.9.el5 1.3.5.9.el5 1.3.5.9.el5 hal 0.5.8.1.19.el5 0.5.8.1.19.el5 0.5.8.1.19.el5 hdparm 6.6.2 6.6.2 6.6.2 hesiod 3.1.0.8 3.1.0.8 3.1.0.8 htmlview 4.0.0.1.el5 4.0.0.1.el5 4.0.0.1.el5 hwdata 0.194.1 0.194.1 0.194.1 ifd-egate 0.05.15 0.05.15 0.05.15 imake 1.0.2.3 1.0.2.3 1.0.2.3 info 4.8.14.el5 4.8.14.el5 4.8.14.el5 initscripts 8.45.14.EL.1 8.45.14.EL.1 8.45.14.EL.1 iproute 2.6.18.4.el5 2.6.18.4.el5 2.6.18.4.el5 ipsec-tools 0.6.5.8.el5 0.6.5.8.el5 0.6.5.8.el5 iptables 1.3.5.1.2.1 1.3.5.1.2.1 1.3.5.1.2.1 iptables-ipv6 1.3.5.1.2.1 1.3.5.1.2.1 1.3.5.1.2.1 iptstate 1.4.1.1.2.2 1.4.1.1.2.2 1.4.1.1.2.2 iputils 20020927.43.el5 20020927.43.el5 20020927.43.el5 irda-utils 0.9.17.2.fc6 0.9.17.2.fc6 0.9.17.2.fc6 irqbalance 1.13.9.el5 1.13.9.el5 1.13.9.el5 jwhois 3.2.3.8.el5 3.2.3.8.el5 3.2.3.8.el5 kbd 1.12.19.el5 1.12.19.el5 1.12.19.el5 kernel 2.6.18.8.1.3.lspp.81.el5 2.6.18.8.1.3.lspp.81.el5 2.6.18.8.1.3.lspp.81.el5 kernel-devel 2.6.18.8.1.3.lspp.81.el5 2.6.18.8.1.3.lspp.81.el5 2.6.18.8.1.3.lspp.81.el5 kernel-headers 2.6.18.8.el5 2.6.18.8.el5 2.6.18.8.el5 keyutils-libs 1.2.1.el5 1.2.1.el5 1.2.1.el5 keyutils-libs-devel 1.2.1.el5 1.2.1.el5 1.2.1.el5 keyutils-libs-devel#2 - - 1.2.1.el5 kpartx 0.4.7.8.el5 0.4.7.8.el5 0.4.7.8.el5 krb5-devel 1.5.17 1.5.17 1.5.17 krb5-libs 1.5.17 1.5.17 1.5.17 krb5-libs#2 - - 1.5.17 krb5-workstation 1.5.17 1.5.17 1.5.17 ksh 20060214.1.4 20060214.1.4 20060214.1.4 kudzu 1.2.57.1.13.1 1.2.57.1.13.1 1.2.57.1.13.1 less 394.5.el5 394.5.el5 394.5.el5 lftp 3.5.1.2.fc6 3.5.1.2.fc6 3.5.1.2.fc6 libFS 1.0.0.3.1 1.0.0.3.1 1.0.0.3.1 libICE 1.0.1.2.1 1.0.1.2.1 1.0.1.2.1 libICE#2 - - 1.0.1.2.1 libIDL 0.8.7.1.fc6 0.8.7.1.fc6 0.8.7.1.fc6 libSM 1.0.1.3.1 1.0.1.3.1 1.0.1.3.1 libSM#2 - - 1.0.1.3.1 libX11 1.0.3.8.el5 1.0.3.8.el5 1.0.3.8.el5 libX11#2 - - 1.0.3.8.el5 libXau 1.0.1.3.1 1.0.1.3.1 1.0.1.3.1 libXau#2 - - 1.0.1.3.1 libXcursor 1.1.7.1.1 1.1.7.1.1 1.1.7.1.1 libXdmcp 1.0.1.2.1 1.0.1.2.1 1.0.1.2.1 libXdmcp#2 - - 1.0.1.2.1 libXext 1.0.1.2.1 1.0.1.2.1 1.0.1.2.1 libXext#2 - - 1.0.1.2.1 libXfixes 4.0.1.2.1 4.0.1.2.1 4.0.1.2.1 libXfont 1.2.2.1.fc6 1.2.2.1.fc6 1.2.2.1.fc6 libXft 2.1.10.1.1 2.1.10.1.1 2.1.10.1.1 libXi 1.0.1.3.1 1.0.1.3.1 1.0.1.3.1 libXi#2 - - 1.0.1.3.1 libXinerama 1.0.1.2.1 1.0.1.2.1 1.0.1.2.1 libXrandr 1.1.1.3.1 1.1.1.3.1 1.1.1.3.1 libXrender 0.9.1.3.1 0.9.1.3.1 0.9.1.3.1 libXres 1.0.1.3.1 1.0.1.3.1 1.0.1.3.1 libXt 1.0.2.3.1.fc6 1.0.2.3.1.fc6 1.0.2.3.1.fc6 libXt#2 - - 1.0.2.3.1.fc6 libXxf86vm 1.0.1.3.1 1.0.1.3.1 1.0.1.3.1 libXxf86vm#2 - - 1.0.1.3.1 libacl 2.2.39.2.1.el5 2.2.39.2.1.el5 2.2.39.2.1.el5 libacl#2 - - 2.2.39.2.1.el5 libacl-devel 2.2.39.2.1.el5 2.2.39.2.1.el5 2.2.39.2.1.el5 libacl-devel#2 - - 2.2.39.2.1.el5 libaio 0.3.106.3.2 0.3.106.3.2 0.3.106.3.2 libaio#2 - - 0.3.106.3.2 Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 18 of 121 © HP, atsec 2004-2007 2007-05-31 libattr 2.4.32.1.1 2.4.32.1.1 2.4.32.1.1 libattr#2 - - 2.4.32.1.1 libattr-devel 2.4.32.1.1 2.4.32.1.1 2.4.32.1.1 libattr-devel#2 - - 2.4.32.1.1 libcap 1.10.26 1.10.26 1.10.26 libcap#2 - - 1.10.26 libcap-devel 1.10.26 1.10.26 1.10.26 libcap-devel#2 - - 1.10.26 libdrm 2.0.2.1.1 2.0.2.1.1 2.0.2.1.1 libdrm#2 - - 2.0.2.1.1 libevent 1.1a.3.2.1 1.1a.3.2.1 1.1a.3.2.1 libfontenc 1.0.2.2.2.el5 1.0.2.2.2.el5 1.0.2.2.2.el5 libgcc 4.1.1.52.el5 4.1.1.52.el5 4.1.1.52.el5 libgcc#2 - - 4.1.1.52.el5 libgcrypt 1.2.3.1 1.2.3.1 1.2.3.1 libgcrypt#2 - - 1.2.3.1 libgomp 4.1.1.52.el5 4.1.1.52.el5 4.1.1.52.el5 libgpg-error 1.4.2 1.4.2 1.4.2 libgpg-error#2 - - 1.4.2 libgssapi 0.10.2 0.10.2 0.10.2 libhugetlbfs 1.0.1.1.el5 - 1.0.1.1.el5 libhugetlbfs-lib 1.0.1.1.el5 - 1.0.1.1.el5 libidn 0.6.5.1.1 0.6.5.1.1 0.6.5.1.1 libjpeg 6b.37 6b.37 6b.37 libjpeg#2 - - 6b.37 libnl 1.0.0.10.pre5.4 1.0.0.10.pre5.4 1.0.0.10.pre5.4 libnotify 0.4.2.6.el5 0.4.2.6.el5 0.4.2.6.el5 libpcap 0.9.4.8.1 0.9.4.8.1 0.9.4.8.1 libpng 1.2.10.7 1.2.10.7 1.2.10.7 libpng#2 - - 1.2.10.7 libselinux 1.33.4.4.el5 1.33.4.4.el5 1.33.4.4.el5 libselinux#2 - - 1.33.4.4.el5 libselinux-devel 1.33.4.4.el5 1.33.4.4.el5 1.33.4.4.el5 libselinux-python 1.33.4.4.el5 1.33.4.4.el5 1.33.4.4.el5 libsemanage 1.9.1.3.el5 1.9.1.3.el5 1.9.1.3.el5 libsemanage-devel 1.9.1.3.el5 1.9.1.3.el5 1.9.1.3.el5 libsepol 1.15.2.1.el5 1.15.2.1.el5 1.15.2.1.el5 libsepol#2 - - 1.15.2.1.el5 libsepol-devel 1.15.2.1.el5 1.15.2.1.el5 1.15.2.1.el5 libstdc++ 4.1.1.52.el5 4.1.1.52.el5 4.1.1.52.el5 libstdc++#2 - - 4.1.1.52.el5 libstdc++-devel 4.1.1.52.el5 4.1.1.52.el5 4.1.1.52.el5 libsysfs 2.0.0.6 2.0.0.6 2.0.0.6 libtermcap 2.0.8.46.1 2.0.8.46.1 2.0.8.46.1 libtermcap#2 - - 2.0.8.46.1 libtermcap-devel 2.0.8.46.1 2.0.8.46.1 2.0.8.46.1 libtiff 3.8.2.7.el5 3.8.2.7.el5 3.8.2.7.el5 libtiff#2 - - 3.8.2.7.el5 libusb 0.1.12.5.1 0.1.12.5.1 0.1.12.5.1 libuser 0.54.7.2.el5.1 0.54.7.2.el5.1 0.54.7.2.el5.1 libuser-devel 0.54.7.2.el5.1 0.54.7.2.el5.1 0.54.7.2.el5.1 libutempter 1.1.4.3.fc6 1.1.4.3.fc6 1.1.4.3.fc6 libutempter#2 - - 1.1.4.3.fc6 libvolume_id 095.14.5.el5 095.14.5.el5 095.14.5.el5 libwnck 2.16.0.4.fc6 2.16.0.4.fc6 2.16.0.4.fc6 libxml2 2.6.26.2.1.2 2.6.26.2.1.2 2.6.26.2.1.2 libxml2-python 2.6.26.2.1.2 2.6.26.2.1.2 2.6.26.2.1.2 logrotate 3.7.4.7 3.7.4.7 3.7.4.7 logwatch 7.3.5 7.3.5 7.3.5 lsof 4.78.3 4.78.3 4.78.3 lvm2 2.02.16.3.el5 2.02.16.3.el5 2.02.16.3.el5 m2crypto 0.16.6.el5.1 0.16.6.el5.1 0.16.6.el5.1 m4 1.4.5.3.el5.1 1.4.5.3.el5.1 1.4.5.3.el5.1 mailcap 2.1.23.1.fc6 2.1.23.1.fc6 2.1.23.1.fc6 mailx 8.1.1.44.2.2 8.1.1.44.2.2 8.1.1.44.2.2 make 3.81.1.1 3.81.1.1 3.81.1.1 man 1.6d.1.1 1.6d.1.1 1.6d.1.1 man-pages 2.39.9.el5 2.39.9.el5 2.39.9.el5 mcelog - - 0.7.1.22.fc6 mcstrans 0.2.3.1.el5 0.2.3.1.el5 0.2.3.1.el5 mdadm 2.5.4.3.el5 2.5.4.3.el5 2.5.4.3.el5 mesa-libGL 6.5.1.7.2.el5 6.5.1.7.2.el5 6.5.1.7.2.el5 mesa-libGL#2 - - 6.5.1.7.2.el5 mgetty 1.1.33.9.fc6 1.1.33.9.fc6 1.1.33.9.fc6 microcode_ctl 1.15.1.40.el5 - 1.15.1.40.el5 mingetty 1.07.5.2.2 1.07.5.2.2 1.07.5.2.2 mkbootdisk 1.5.3.2.1 - 1.5.3.2.1 mkinitrd 5.1.19.6.1 5.1.19.6.1 5.1.19.6.1 Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 19 of 121 © HP, atsec 2004-2007 2007-05-31 mkinitrd#2 - - 5.1.19.6.1 mktemp 1.5.23.2.2 1.5.23.2.2 1.5.23.2.2 mlocate 0.15.1.el5 0.15.1.el5 0.15.1.el5 module-init-tools 3.3.0.pre3.1.16.el5 3.3.0.pre3.1.16.el5 3.3.0.pre3.1.16.el5 mtools 3.9.10.2.fc6 3.9.10.2.fc6 3.9.10.2.fc6 mtr 0.71.3.1 0.71.3.1 0.71.3.1 nano 1.3.12.1.1 1.3.12.1.1 1.3.12.1.1 nash 5.1.19.6.1 5.1.19.6.1 5.1.19.6.1 nc 1.84.10.fc6 1.84.10.fc6 1.84.10.fc6 ncurses 5.5.24.20060715 5.5.24.20060715 5.5.24.20060715 ncurses#2 - - 5.5.24.20060715 net-snmp-libs 5.3.1.14.el5 5.3.1.14.el5 5.3.1.14.el5 net-tools 1.60.73 1.60.73 1.60.73 netlabel_tools 0.17.9.el5 0.17.9.el5 0.17.9.el5 newt 0.52.2.9 0.52.2.9 0.52.2.9 nfs-utils 1.0.9.16.el5 1.0.9.16.el5 1.0.9.16.el5 nfs-utils-lib 1.0.8.7.2 1.0.8.7.2 1.0.8.7.2 notification-daemon 0.3.5.8.el5 0.3.5.8.el5 0.3.5.8.el5 nscd 2.5.12 2.5.12 2.5.12 nspr 4.6.5.1.el5 4.6.5.1.el5 4.6.5.1.el5 nspr#2 - - 4.6.5.1.el5 nss 3.11.5.1.el5 3.11.5.1.el5 3.11.5.1.el5 nss#2 - - 3.11.5.1.el5 nss-tools 3.11.5.1.el5 3.11.5.1.el5 3.11.5.1.el5 nss_db 2.2.35.1 2.2.35.1 2.2.35.1 nss_db#2 - - 2.2.35.1 nss_ldap 253.3 253.3 253.3 nss_ldap#2 - - 253.3 ntsysv 1.3.30.1.1 1.3.30.1.1 1.3.30.1.1 numactl 0.9.8.2.el5 0.9.8.2.el5 0.9.8.2.el5 numactl#2 - - 0.9.8.2.el5 openldap 2.3.27.5 2.3.27.5 2.3.27.5 openldap#2 - - 2.3.27.5 openssh 4.3p2.21.el5 4.3p2.21.el5 4.3p2.21.el5 openssh-clients 4.3p2.21.el5 4.3p2.21.el5 4.3p2.21.el5 openssh-server 4.3p2.21.el5 4.3p2.21.el5 4.3p2.21.el5 openssl 0.9.8b.8.3.el5 0.9.8b.8.3.el5 0.9.8b.8.3.el5 openssl#2 - - 0.9.8b.8.3.el5 openssl-devel 0.9.8b.8.3.el5 0.9.8b.8.3.el5 0.9.8b.8.3.el5 pam 0.99.6.2.3.22.el5 0.99.6.2.3.22.el5 0.99.6.2.3.22.el5 pam#2 - - 0.99.6.2.3.22.el5 pam-devel 0.99.6.2.3.22.el5 0.99.6.2.3.22.el5 0.99.6.2.3.22.el5 pam_ccreds 3.5 3.5 3.5 pam_ccreds#2 - - 3.5 pam_krb5 2.2.11.1 2.2.11.1 2.2.11.1 pam_krb5#2 - - 2.2.11.1 pam_passwdqc 1.0.2.1.2.2 1.0.2.1.2.2 1.0.2.1.2.2 pam_passwdqc#2 - - 1.0.2.1.2.2 pam_pkcs11 0.5.3.23 0.5.3.23 0.5.3.23 pam_pkcs11#2 - - 0.5.3.23 pam_smb 1.1.7.7.2.1 1.1.7.7.2.1 1.1.7.7.2.1 pam_smb#2 - - 1.1.7.7.2.1 pango 1.14.9.3.el5 1.14.9.3.el5 1.14.9.3.el5 paps 0.6.6.17.el5 0.6.6.17.el5 0.6.6.17.el5 parted 1.8.1.4.el5 1.8.1.4.el5 1.8.1.4.el5 parted#2 - - 1.8.1.4.el5 passwd 0.73.1 0.73.1 0.73.1 patch 2.5.4.29.2.2 2.5.4.29.2.2 2.5.4.29.2.2 pax 3.4.1.2.2 3.4.1.2.2 3.4.1.2.2 pciutils 2.2.3.4 2.2.3.4 2.2.3.4 pciutils-devel 2.2.3.4 2.2.3.4 2.2.3.4 pciutils-devel#2 - - 2.2.3.4 pcmciautils 014.5 014.5 014.5 pcre 6.6.1.1 6.6.1.1 6.6.1.1 pcsc-lite 1.3.1.7 1.3.1.7 1.3.1.7 pcsc-lite-libs 1.3.1.7 1.3.1.7 1.3.1.7 perl 5.8.8.10 5.8.8.10 5.8.8.10 perl-Digest-HMAC 1.01.15 1.01.15 1.01.15 perl-Digest-SHA1 2.11.1.2.1 2.11.1.2.1 2.11.1.2.1 perl-String-CRC32 1.4.2.fc6 1.4.2.fc6 1.4.2.fc6 pinfo 0.6.9.1.fc6 0.6.9.1.fc6 0.6.9.1.fc6 pkgconfig 0.21.1.fc6 0.21.1.fc6 0.21.1.fc6 pkinit-nss 0.3.5.1.el5 0.3.5.1.el5 0.3.5.1.el5 pm-utils 0.19.3 0.19.3 0.19.3 policycoreutils 1.33.12.8.el5 1.33.12.8.el5 1.33.12.8.el5 policycoreutils-newrole 1.33.12.8.el5 1.33.12.8.el5 1.33.12.8.el5 popt 1.10.2.37.el5 1.10.2.37.el5 1.10.2.37.el5 Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 20 of 121 © HP, atsec 2004-2007 2007-05-31 portmap 4.0.65.2.2.1 4.0.65.2.2.1 4.0.65.2.2.1 postfix 2.3.3.2 2.3.3.2 2.3.3.2 ppp 2.4.4.1.el5 2.4.4.1.el5 2.4.4.1.el5 prctl - 1.4.5.2.1 - prelink 0.3.9.2 - 0.3.9.2 procps 3.2.7.8.1.el5 3.2.7.8.1.el5 3.2.7.8.1.el5 psacct 6.3.2.41.1 6.3.2.41.1 6.3.2.41.1 psmisc 22.2.5 22.2.5 22.2.5 pyOpenSSL 0.6.1.p24.7.2.2 0.6.1.p24.7.2.2 0.6.1.p24.7.2.2 pygobject2 2.12.1.5.el5 2.12.1.5.el5 2.12.1.5.el5 python 2.4.3.19.el5 2.4.3.19.el5 2.4.3.19.el5 python-devel 2.4.3.19.el5 2.4.3.19.el5 2.4.3.19.el5 python-devel#2 - - 2.4.3.19.el5 python-elementtree 1.2.6.5 1.2.6.5 1.2.6.5 python-sqlite 1.1.7.1.2.1 1.1.7.1.2.1 1.1.7.1.2.1 python-urlgrabber 3.1.0.2 3.1.0.2 3.1.0.2 quota 3.13.1.2.3.2.el5 3.13.1.2.3.2.el5 3.13.1.2.3.2.el5 rdate 1.4.6 1.4.6 1.4.6 rdist 6.1.5.44 6.1.5.44 6.1.5.44 readahead 1.3.7.el5 1.3.7.el5 1.3.7.el5 readline 5.1.1.1 5.1.1.1 5.1.1.1 readline#2 - - 5.1.1.1 readline-devel 5.1.1.1 5.1.1.1 5.1.1.1 readline-devel#2 - - 5.1.1.1 redhat-logos 4.9.16.1 4.9.16.1 4.9.16.1 redhat-lsb 3.1.12.2.EL 3.1.12.2.EL 3.1.12.2.EL redhat-lsb#2 - - 3.1.12.2.EL redhat-menus 6.7.8.1.el5 6.7.8.1.el5 6.7.8.1.el5 redhat-release 5Server.5.0.0.9 5Server.5.0.0.9 5Server.5.0.0.9 redhat-release-notes 5Server.5 5Server.5 5Server.5 rhel-instnum 1.0.7.1.el5 1.0.7.1.el5 1.0.7.1.el5 rhn-check 0.4.13.1.el5 0.4.13.1.el5 0.4.13.1.el5 rhn-client-tools 0.4.13.1.el5 0.4.13.1.el5 0.4.13.1.el5 rhn-setup 0.4.13.1.el5 0.4.13.1.el5 0.4.13.1.el5 rhnlib 2.2.5.1.el5 2.2.5.1.el5 2.2.5.1.el5 rhnsd 4.6.1.1.el5 4.6.1.1.el5 4.6.1.1.el5 rhpl 0.194.1.1 0.194.1.1 0.194.1.1 rmt 0.4b41.2.fc6 0.4b41.2.fc6 0.4b41.2.fc6 rng-utils 2.0.1.14.1.fc6 2.0.1.14.1.fc6 2.0.1.14.1.fc6 rootfiles 8.1.1.1.1 8.1.1.1.1 8.1.1.1.1 rp-pppoe 3.5.32.1 3.5.32.1 3.5.32.1 rpm 4.4.2.37.el5 4.4.2.37.el5 4.4.2.37.el5 rpm-build 4.4.2.37.el5 4.4.2.37.el5 4.4.2.37.el5 rpm-libs 4.4.2.37.el5 4.4.2.37.el5 4.4.2.37.el5 rpm-python 4.4.2.37.el5 4.4.2.37.el5 4.4.2.37.el5 rsh 0.17.37.el5 0.17.37.el5 0.17.37.el5 rsync 2.6.8.3.1 2.6.8.3.1 2.6.8.3.1 salinfo - 1.1.2.el5 - sed 4.1.5.5.fc6 4.1.5.5.fc6 4.1.5.5.fc6 selinux-policy 2.4.6.67.el5 2.4.6.67.el5 2.4.6.67.el5 selinux-policy-devel 2.4.6.67.el5 2.4.6.67.el5 2.4.6.67.el5 selinux-policy-mls 2.4.6.67.el5 2.4.6.67.el5 2.4.6.67.el5 selinux-policy-strict 2.4.6.67.el5 2.4.6.67.el5 2.4.6.67.el5 selinux-policy-targeted 2.4.6.67.el5 2.4.6.67.el5 2.4.6.67.el5 setarch 2.0.1.1 2.0.1.1 2.0.1.1 setools 3.0.3.el5 3.0.3.el5 3.0.3.el5 setserial 2.17.19.2.2 2.17.19.2.2 2.17.19.2.2 setup 2.5.58.1.el5 2.5.58.1.el5 2.5.58.1.el5 setuptool 1.19.2.1 1.19.2.1 1.19.2.1 shadow-utils 4.0.17.12.el5 4.0.17.12.el5 4.0.17.12.el5 slang 2.0.6.4.el5 2.0.6.4.el5 2.0.6.4.el5 smartmontools 5.36.3.1.el5 5.36.3.1.el5 5.36.3.1.el5 sos 1.3.1.el5 1.3.1.el5 1.3.1.el5 specspo 13.1.el5 13.1.el5 13.1.el5 sqlite 3.3.6.2 3.3.6.2 3.3.6.2 star 1.5a75.1 1.5a75.1 1.5a75.1 startup-notification 0.8.4.1 0.8.4.1 0.8.4.1 strace 4.5.15.1.el5 4.5.15.1.el5 4.5.15.1.el5 stunnel 4.15.2 4.15.2 4.15.2 sudo 1.6.8p12.10 1.6.8p12.10 1.6.8p12.10 swig 1.3.29.2.el5 1.3.29.2.el5 1.3.29.2.el5 symlinks 1.2.24.2.2 1.2.24.2.2 1.2.24.2.2 sysfsutils 2.0.0.6 2.0.0.6 2.0.0.6 sysklogd 1.4.1.39.2 1.4.1.39.2 1.4.1.39.2 syslinux 3.11.4 - 3.11.4 sysreport 1.4.3.10.el5 1.4.3.10.el5 1.4.3.10.el5 system-config-network-tui 1.3.99.1.el5 1.3.99.1.el5 1.3.99.1.el5 system-config-securitylevel-tui 1.6.29.1.1.el5 1.6.29.1.1.el5 1.6.29.1.1.el5 Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 21 of 121 © HP, atsec 2004-2007 2007-05-31 talk 0.17.29.2.2 0.17.29.2.2 0.17.29.2.2 tar 1.15.1.23.el5 1.15.1.23.el5 1.15.1.23.el5 tcl 8.4.13.3.fc6 8.4.13.3.fc6 8.4.13.3.fc6 tcl#2 - - 8.4.13.3.fc6 tcp_wrappers 7.6.40.2.1 7.6.40.2.1 7.6.40.2.1 tcp_wrappers#2 - - 7.6.40.2.1 tcpdump 3.9.4.8.1 3.9.4.8.1 3.9.4.8.1 tcsh 6.14.12.el5 6.14.12.el5 6.14.12.el5 telnet 0.17.38.el5 0.17.38.el5 0.17.38.el5 termcap 5.5.1.20060701.1 5.5.1.20060701.1 5.5.1.20060701.1 texinfo 4.8.14.el5 4.8.14.el5 4.8.14.el5 time 1.7.27.2.2 1.7.27.2.2 1.7.27.2.2 tk 8.4.13.3.fc6 8.4.13.3.fc6 8.4.13.3.fc6 tk#2 - - 8.4.13.3.fc6 tmpwatch 2.9.7.1.1.el5.1 2.9.7.1.1.el5.1 2.9.7.1.1.el5.1 traceroute 2.0.1.2.el5 2.0.1.2.el5 2.0.1.2.el5 tree 1.5.0.4 1.5.0.4 1.5.0.4 ttmkfdir 3.0.9.23.el5 3.0.9.23.el5 3.0.9.23.el5 tzdata 2006m.2.fc6 2006m.2.fc6 2006m.2.fc6 udev 095.14.5.el5 095.14.5.el5 095.14.5.el5 unix2dos 2.2.26.2.2 2.2.26.2.2 2.2.26.2.2 unzip 5.52.2.2.1 5.52.2.2.1 5.52.2.2.1 urw-fonts 2.3.6.1.1 2.3.6.1.1 2.3.6.1.1 usbutils 0.71.2.1 0.71.2.1 0.71.2.1 usermode 1.88.3.el5 1.88.3.el5 1.88.3.el5 util-linux 2.13.0.44.el5 2.13.0.44.el5 2.13.0.44.el5 vconfig 1.9.2.1 1.9.2.1 1.9.2.1 vim-minimal 7.0.109.3 7.0.109.3 7.0.109.3 vixie-cron 4.1.68.el5 4.1.68.el5 4.1.68.el5 vsftpd 2.0.5.10.el5 2.0.5.10.el5 2.0.5.10.el5 wget 1.10.2.7.el5 1.10.2.7.el5 1.10.2.7.el5 which 2.16.7 2.16.7 2.16.7 wireless-tools 28.2.el5 28.2.el5 28.2.el5 wireless-tools#2 - - 28.2.el5 words 3.0.9 3.0.9 3.0.9 wpa_supplicant 0.4.8.10.1.fc6 0.4.8.10.1.fc6 0.4.8.10.1.fc6 xinetd 2.3.14.10.el5 2.3.14.10.el5 2.3.14.10.el5 xorg-x11-filesystem 7.1.2.fc6 7.1.2.fc6 7.1.2.fc6 xorg-x11-font-utils 7.1.2 7.1.2 7.1.2 xorg-x11-xfs 1.0.2.3.1 1.0.2.3.1 1.0.2.3.1 yp-tools 2.9.0.1 2.9.0.1 2.9.0.1 ypbind 1.19.7.el5 1.19.7.el5 1.19.7.el5 yum 3.0.1.5.el5 3.0.1.5.el5 3.0.1.5.el5 yum-metadata-parser 1.0.8.fc6 1.0.8.fc6 1.0.8.fc6 yum-rhn-plugin 0.4.3.1.el5 0.4.3.1.el5 0.4.3.1.el5 yum-updatesd 3.0.1.5.el5 3.0.1.5.el5 3.0.1.5.el5 zip 2.31.1.2.2 2.31.1.2.2 2.31.1.2.2 zlib 1.2.3.3 1.2.3.3 1.2.3.3 zlib#2 - - 1.2.3.3 zlib-devel 1.2.3.3 1.2.3.3 1.2.3.3 zlib-devel#2 - - 1.2.3.3 The following remarks need to be considered when reading the table above: • The x86_64 systems support execution of 64bit and 32bit binaries. To support this, some packages are installed and listed twice, once for each word size, using the ”#2” suffix to the package name for the second copy of the package. The suffix is not part of the package name. • The “redhat-release” package has a different package name for the “Client” and “Server” flavors of the RHEL product. This is informational data only and has no impact on security functionality. 2.4 Configurations The evaluated configurations are defined as follows. • The CC evaluated package set must be selected at install time in accordance with the description provided in the Evaluated Configuration Guide and installed accordingly. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 22 of 121 © HP, atsec 2004-2007 2007-05-31 • Red Hat Enterprise Linux supports the use of IPv4 and IPv6. Only the functional equivalent of IPv6 to IPv4 is covered in this evaluation, additional mechanisms defined for IPv6 like multicast or IPSEC encryption is not tested. • Both installation from CD-ROM or DVD-ROM and installation from a defined disk partition are supported. • The default configuration for identification and authentication are the defined password based PAM modules. Support for other authentication options e.g. smartcard authentication, is not included in the evaluation configuration. • If the system console is used, it must be connected directly to the system and afforded the same physical protection as the server. • The chosen mode of operation (LSPP/RBAC or CAPP) must be configured by following the instructions pertaining to the respective mode of operation in the Evaluated Confuguration Guide. The TOE comprises a single server machine (and optional peripherals) listed in section 2.4.2 running the system software listed the package list in section 2.3 (a server running the above listed software is referred to as a “TOE server” below). Several TOE servers may be interlinked in a network, and individual networks may be joined by bridges and/or routers, or by TOE servers which act as routers and/or gateways. Each of the TOE servers implements its own security policy. The TOE does not include any synchronization function for those policies. As a result a single user may have user accounts on each of those servers with different user IDs, different roles, and other different attributes. (A synchronization method may optionally be used, but it not part of the TOE and must not use methods that conflict with the TOE requirements.)If other systems are connected to a network they need to be configured and managed by the same authority using an appropriate security policy that does not conflict with the security policy of the TOE. All links between this network and untrusted networks (e. g. the Internet) need to be protected by appropriate measures such as carefully configured firewall systems that prohibit attacks from the untrusted networks. Those protections are part of the TOE environment. 2.4.1 File systems The following file system types are supported: • Ext3 journaling filesystem, • VFAT filesystem for the /boot/efi partition on Itanium systems, • the ISO 9660 filesystem for CD-ROM drives, • the ISO 9660 filesystem for DVD-ROM drives, • The process file system, procfs (/proc), provides access to the process image of each process on the machine as if the process were a “file”. Process access decisions are enforced by DAC attributes inferred from the underlying process’ DAC attributes. Additional restrictions apply for specific objects in this file system. • The sysfs filesystem (sysfs) used to export and handle non-process related kernel information such as driver specific information. • The temporary filesystem (tmpfs) used as a temporary RAM based file system. • The pseudoterminal device file system (devpts) used to provide pseudo terminal support. • The virtual root file system (rootfs) used temporarily during system startup. • The miscellaneous binary file format registration file system (binfmt_misc) used to configure interpreters for executing binary files based on file header information. • The Security Enhanced Linux file system (selinuxfs) used for configuring the selinux system. 2.4.2 TOE hardware The hardware on which the software components of the TOE are executed is considered part of the TOE. The TOE includes each of the following hardware platforms. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 23 of 121 © HP, atsec 2004-2007 2007-05-31 • HP Intel Itanium2 (single and multi-core) processor based servers: o HP Integrity Superdome product line o HP Integrity rx product line o HP Integrity cx product line o HP Integrity BL product line • Intel Xeon based servers with EM64T 64bit extensions (single and multi-core), and HP AMD Opteron processor (single and multi-core): o HP Proliant ML product line (EM64T capable models) o HP Proliant DL product line (EM64T capable or Opteron models) o HP ProLiant BL product line (EM64T capable or Opteron models) • HP Intel Pentium and Xeon processor based servers without EM64T extensions: o HP Proliant ML product line (except EM64T capable models) o HP Proliant DL product line (except EM64T capable or Opteron models) o HP Proliant BL product line (except EM64T capable or Opteron models) • HP Intel Xeon processor based systems: o HP xw product line • HP Intel Pentium 4 processor based systems: o HP xw product line o HP Compaq dc series product line The hardware that is allowed to be used for the evaluated configuration consists of the above listed platforms. However, it is not permitted to install the TOE within a nPar hardware partition. All network adapters supported by the TOE are part of the TOE. 2.4.2.1 Peripherials The following types of printers in the CAPP mode are supported: • Printers supporting PCL version 4 (parallel, USB and Ethernet) • Printers supporting PostScript level 1 (parallel, USB and Ethernet) The following types of printers in the LSPP/RBAC mode are supported: • Printers supporting PCL version 4 (parallel, USB) • Printers supporting PostScript level 1 (parallel, USB) Only printers supporting the above mentioned languages and are connected to the specified interfaces are allowed. The following additional peripherals can be used with the TOE preserving the security functionality: ƒ all terminals supported by the TOE software (except hot pluggable devices connected via USB or IEEE 1394 (Firewire) interfaces). ƒ all storage devices and backup devices supported by the TOE software (hard disks, CDROM and DVDROM drives, streamer drives, floppy disk drives) (except hot pluggable devices connected via USB or IEEE 1394 (Firewire) interfaces). Note: peripheral devices are part of the TOE environment. Note: the peripherals are physical peripherals for all systems. Note: Excluding hot pluggable devices connected via USB does not exclude all USB devices. USB keyboards and mice may be attached provided they are connected before booting the operating system. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 24 of 121 © HP, atsec 2004-2007 2007-05-31 3 TOE Security Environment 3.1 Introduction The statement of TOE security environment describes the security aspects of the environment in which the TOE is intended to be used and the manner in which it is expected to be deployed. To this end, the statement of TOE security environment identifies the list of assumptions made on the operational environment (including physical and procedural measures) and the intended method of use of the product, defines the threats that the product is designed to counter, and the organizational security policies with which the product is designed to comply. 3.2 Threats The assumed security threats are listed below. The IT assets to be protected comprise the information stored, processed or transmitted by the TOE. The term “information” is used here to refer to all data held within a server. The TOE counters the general threat of unauthorized access to information, where "access" includes disclosure, modification and destruction. The threat agents can be categorized as either: y unauthorized users of the TOE, i.e. individuals who have not been granted the right to access the system; or y authorized users of the TOE, i.e. individuals who have been granted the right to access the system. The threat agents are assumed to originate from a well managed user community in a non-hostile working environment, and hence the product protects against threats of obvious security vulnerabilities that might be exploited in the intended environment for the TOE. The TOE in accordance with the strength of function claimed protects against straightforward or intentional breach of TOE security by attackers possessing a low attack potential. The threats listed below are grouped according to whether or not they are countered by the TOE. Those that are not countered by the TOE are countered by environmental or external mechanisms. 3.2.1 Threats countered by the TOE The following threats have been gathered from the different protection profiles this ST claims conformance to. Rather than combining similar threats into one, this ST lists the different threats as found in the respective PPs, recognizing that they are overlapping in several areas. In all modes of operation, the TOE counters these threats: T.UAUSER An attacker (possibly, but not necessarily, an unauthorized user of the TOE) may impersonate an authorized user of the TOE. This includes the threat of an authorized user that tries to impersonate as another authorized user without knowing the authentication information. T.UAACCESS An authorized user of the TOE may access information resources without having permission from the person who owns, or is responsible for, the information resource for the type of access. T.COMPROT An attacker (possibly, but not necessarily, an unauthorized user of the TOE) may intercept a communication link between the TOE and another trusted IT product to read or modify information transferred between the TOE and the other trusted IT product (which may be another instantiation of the TOE) using defined protocols (SSH or SSL) in a way that can not be detected by the TOE or the other trusted IT product. In LSPP/RBAC mode, the TOE additionaly counters these threats: T.OPERATE Compromise of the IT assets may occur because of improper administration and operation of the TOE. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 25 of 121 © HP, atsec 2004-2007 2007-05-31 T.ROLEDEV The development and assignment of user roles may be done in a manner that undermines security. 3.2.2 Threats to be countered by measures within the TOE environment The following threats to the system need to be countered in the TOE environment: TE.HWMF An attacker with legitimate physical access to the hardware of the TOE (examples are maintenance personnel or legitimate users) or environmental conditions may cause a hardware malfunction with the effect that a user (normal or administrative) is losing stored data due to this hardware malfunction. An attacker may cause such a hardware malfunction either by having physical access to the hardware the TOE is running on or by executing software that capable of causing hardware malfunction. Note that such a hardware malfunction may be caused accidently without malicious intent by persons having physical access to the TOE. TE.COR_FILE An attacker (including but not limited to an unauthorized user of the TOE) or environmental conditions such as a hardware malfunction may intentionally or accidentally modify or corrupt security enforcing or relevant files of the TOE without an administrative user being able to detect this. An attacker may corrupt such files either by having physical access to the TOE hardware, by booting other software than the TOE software in its evaluated configuration, or by modifying or corrupting files on backup media. Note that such a corruption may be caused accidently without malicious intent by persons having legitimate access to media where such data is stored. 3.3 Organizational Security Policies The following organizational security policies (OSPs) have been gathered from the different protection profiles this ST claims conformance to. Rather than combining similar OSPs into one, this ST lists the different OSPs as found in the respective PPs, recognizing that they are overlapping in several areas. P.AUTHORIZED_USERS Only those users who have been authorized to access the information within the system may access the system. P.NEED_TO_KNOW The organization must define a discretionary access control policy on a need-to-know basis which can be modeled based on: a) the owner of the object; and b) the identity of the subject attempting the access; and c) the implicit and explicit access rights to the object granted to the subject by the object owner or an administrative user. P.ACCOUNTABILITY The users of the system shall be held accountable for their actions within the system. P.ACCESS (LSPP/RBAC mode only) Access rights to specific data objects are determined by the owner of the object, the role of the subject attempting access, and the implicit and explicit access rights to the object granted to the role by the object owner. P.CLASSIFICATION (LSPP/RBAC mode only) The system must limit the access to information based on sensitivity, as represented by a label, of the information contained in objects, and the formal clearance of users, as represented by subjects, to access that information. The access rules enforced prevent a subject from accessing information which is of higher sensitivity than it is operating at and prevent a subject from causing information from being downgraded to a lower sensitivity. Note: The method for classification of information is made based on criteria set forth by the organization. This is usually done based on relative value to the organization and its interest in limiting dissemination of that information. The determination of classification of information is outside the scope of the IT system; the IT system is only expected to enforce the classification rules, not determine classification. The method for determining clearances is also outside Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 26 of 121 © HP, atsec 2004-2007 2007-05-31 the scope of the IT system. It is essentially based on the trust placed in individual users by the organization. To some extent, it is also dependent upon the individual’s role within the organization. 3.4 Assumptions This section indicates the minimum physical and procedural measures required to maintain security of the Red Hat Enterprise Linux product. 3.4.1 Physical Aspects A.LOCATE The processing resources of the TOE will be located within controlled access facilities which will prevent unauthorized physical access. A.PROTECT The TOE hardware and software critical to security policy enforcement will be protected from unauthorized physical modification. 3.4.2 Personnel Aspects A.MANAGE It is assumed that there are one or more competent individuals who are assigned to manage the TOE and the security of the information it contains. In LSPP/RBAC mode, these individuals will have sole responsibility for the following functions: (a) create and maintain roles (b) establish and maintain relationships among roles (c) Assignment and Revocation of users to roles. In addition these individuals (as ‘owners of the entire corporate data’), along with object owners will have the ability to assign and revoke object access rights to roles. A.NO_EVIL_ADMIN The system administrative personnel are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the administrator documentation. A.COOP 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. A.UTRAIN Authorized users are trained to use the security functionality provided by the system appropriately. A.UTRUST Authorized users are trusted to accomplish some task or group of tasks within a secure IT environment by exercising complete control over their data. A.ACCESS (LSPP/RBAC mode only): Rights for users to gain access and perform operations on information are based on their membership in one or more roles. These roles are granted to the users by the TOE Administrator. These roles accurately reflect the users job function, responsibilities, qualifications, and/or competencies within the enterprise. A.OWNER (LSPP/RBAC mode only): A limited set of users is given the rights to “create new data objects” and they become owners for those data objects. The organization is the owner of the rest of the information under the control of TOE. 3.4.3 Procedural Assumptions A. CLEARANCE (LSPP/RBAC mode only): Procedures exist for granting users authorization for access to specific security levels. A. SENSITIVITY (LSPP/RBAC mode only): Procedures exist for establishing the security level of all information imported into the system, for establishing the security level for all peripheral devices (e.g., printers, tape drives, disk drives) attached to the TOE, and marking a sensitivity label on all output generated. 3.4.4 Connectivity Aspects A.NET_COMP All network components (such as bridges and routers) are assumed to correctly pass data without modification. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 27 of 121 © HP, atsec 2004-2007 2007-05-31 A.PEER Any other system with which the TOE communicates is assumed to be under the same management control and operate under the same security policy constraints. There are no security requirements which address the need to trust external systems or the communications links to such systems. A.CONNECT All connections to peripheral devices and all network connections not using the secured protocols SSH v2 or SSL v3 reside within the controlled access facilities. Internal communication paths to access points such as terminals or other systems are assumed to be adequately protected. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 28 of 121 © HP, atsec 2004-2007 2007-05-31 4 Security Objectives 4.1 Security Objectives for the TOE O.AUTHORIZATION The TOE must ensure that only authorized users gain access to the TOE and its resources. O.DISCRETIONARY_ACCESS The TSF must control access to resources based on identity of users. The TSF must allow authorized users to specify which resources may be accessed by which users. O.MANDATORY_ACCESS (LSPP/RBAC mode only): The TSF must control access to resources based upon the sensitivity and categories of the information being accessed and the clearance of the subject attempting to access that information. O.AUDITING The TSF must record the security relevant actions of users of the TOE. The TSF must present this information to authorized administrators. O.RESIDUAL_INFO The TOE must ensure that any information contained in a protected resource is not released when the resource is recycled. O.MANAGE The TSF must provide all the functions and facilities necessary to support administrative users that are responsible for the management of TOE security and must ensure that only administrative users are able to access such functionality. O.ENFORCEMENT The TSF must be designed and implemented in a manner which ensures that the organizational policies are enforced in the target environment The TOE security policy is enforced in a manner which ensures that the organizational policies are enforced in the target environment i.e. the integrity of the TSF is protected. O.COMPROT The TSF must be designed and implemented in a manner that allows for establishing a trusted channel between the TOE and another trusted IT product that protects the user data transferred over this channel from disclosure and undetected modification. O.DUTY (LSPP/RBAC mode only): The TOE must provide the capability of enforcing ‘separation of duties’, so that no single user has to be granted the right to perform all operations on important information. O.HIERARCHICAL (LSPP/RBAC mode only): The TOE must allow hierarchical definitions of roles. Hierarchical definition of roles means the ability to define roles in terms of other roles. This saves time and allows for more convenient administration of the TOE. O.ROLE (LSPP/RBAC mode only): The TOE must prevent users from gaining access to and performing operations on its resources/objects unless they have been granted access by the resource/object owner or they have been assigned to a role (by an authorized administrator) which permits those operations. 4.2 Security Objectives for the TOE Environment All security requirements listed in this section are targeted at the non-IT environment of the TOE. OE.ADMIN Those responsible for the administration of the TOE are competent and trustworthy individuals, capable of managing the TOE and the security of the information it contains. OE.CREDEN Those responsible for the TOE must ensure that user authentication data is stored securely and not disclosed to unauthorized individuals. In particular: Procedures must be established to ensure that user passwords generated by an administrator during user account creation or modification are distributed in a secure manner, as appropriate for the purpose of the system. The media on which authentication data is stored must not be physically removable from the system by other than administrative users. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 29 of 121 © HP, atsec 2004-2007 2007-05-31 Users must not disclose their passwords to other individuals. OE.INSTALL Those responsible for the TOE must establish and implement procedures to ensure that the hardware, software and firmware components that comprise the system are distributed, installed and configured in a secure manner. OE.PHYSICAL Those responsible for the TOE must ensure that those parts of the TOE critical to security policy are protected from physical attack which might compromise IT security objectives. OE.INFO_PROTECT Those responsible for the TOE must establish and implement procedures to ensure that information is protected in an appropriate manner. In particular: ƒ DAC protections on security critical files (such as configuration files and authentication databases) shall always be set up correctly. ƒ Network and peripheral cabling must be approved for the transmittal of the most sensitive data held by the system. Such physical links are assumed to be adequately protected against threats to the confidentiality and integrity of the data transmitted unless one of the secure protocols provided by the TOE is used for the communication with another trusted entity. ƒ This requires that users are trained to perform those tasks properly and trustworthy to not deliberately misuse their access to information and pass it on to somebody that does not have the right to access the information. OE.MAINTENANCE Administrative users of the TOE must ensure that any diagnostics facilities provided by the product are invoked at every scheduled preventative maintenance period. OE.RECOVER Those responsible for the TOE must ensure that procedures and/or mechanisms are provided to assure that, after system failure or other discontinuity, recovery without a protection (i.e., security) compromise is obtained. OE.SOFTWARE_IN Those responsible for the TOE shall ensure that the system shall be configured so that only an administrative user can introduce new trusted software into the system. OE.SERIAL_LOGIN Those responsible for the TOE shall implement procedures to ensure that users clear the screen before logging off where serial login devices are used. OE.CLASSIFICATION (LSPP mode only) Those responsible for the TOE must ensure that users of the TOE are cleared for access to information depending on the classification of the information. They must also ensure that information is correctly classified to be protected by the security functions of the TOE. The following security objective applies in environments where specific threats to networked systems need to be countered. (Either physical protection measures or cryptographic controls may be applied to achieve this objective. The TOE provides some security functions that can be used to protect communication links, but the TOE does not enforce that those functions are used for all communication links. Communication links not protected by the functions provided as part of the TOE or communication links that need protection against interruption of communication have to be protected by security measures in the TOE environment.) OE.PROTECT Those responsible for the TOE must ensure that procedures and/or mechanisms exist to ensure that data transferred between servers is secured from disclosure and tampering when using communication links not protected by the use of the SSL or SSH protocols. (Note that interruption of communication is not prevented by the use of those protocols. If protection against interruption of communication is required, adequate protection in the TOE environment has to be established for all communication links.). Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 30 of 121 © HP, atsec 2004-2007 2007-05-31 5 Security Requirements 5.1 TOE Security Functional Requirements Most of the following security functional requirements are taken from the “Controlled Access Protection Profile”, [CAPP], the “Labeled Access Protection Profile” [LSPP] and the “Role-Based Accees Control Protection Profile” [RBACPP]. The requirement FMT_SMF.1 was added due to an added dependency in [CC]. The requirements FCS_CKM.1, FCS_CKM.2, FCS_COP.1, FDP_UCT.1, FDP_UIT.1, FMT_MSA.2 and FTP_ITC.1 represent TOE- specific extensions to the requirements defined by the protection profiles. [CAPP], [LSPP] and [RBACPP] have already performed some instantiations and even some refinements of the security functional requirements as defined in the Common Criteria. Those instantiations and refinements are marked in bold within each of the requirements. In addition this Security Target has instantiated and refined the requirements as stated in [CAPP], [LSPP] and [RBACPP]. Those instantiations and refinements that are specific for this Security Target are marked in bold, italic and blue. Security functional requirements in addition to those taken from [CAPP], [LSPP] or [RBACPP] are shown in green with TOE-specific instantiations marked in bold, italic and green. 5.1.1 Security Audit (FAU) 5.1.1.1 Audit Data Generation (FAU_GEN.1) FAU_GEN.1.1 The TSF shall be able to generate an audit record of the auditable events listed in column “Event” of Table 5-1 (Auditable Events). This includes all auditable events for the basic level of audit, except FIA_UID.1’s user identity during failures. FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; b) The sensitivity labels of subjects, objects, or information involved; c) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST the following information i. For each invocation of a security function, the RBAC Administrator role that made invocation of that security function possible. ii. For each access control action on the user data, the role that made possible the invocation of that action. d) The additional information specified in the “Details” column of Table 5-1 (Auditable Events). Table 5-1: Auditable Events Component Event Details (Event Names) FAU_GEN.1 Start-up and shutdown of the audit functions. Events DAEMON_START, DAEMON_END, generated by auditd FAU_GEN.2 None FAU_SAR.1 Reading of information from the audit records. syscall open (on the audit log files) Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 31 of 121 © HP, atsec 2004-2007 2007-05-31 Component Event Details (Event Names) FAU_SAR.2 Unsuccessful attempts to read information from the audit records. like FAU_SAR.1, but with negative results FAU_SAR.3 None FAU_SEL.1 All modifications to the audit configuration that occur while the audit collection functions are operating. Events DAEMON_CONFIG, DAEMON_RECONFIG generated by auditd; syscalls open, link, unlink, rename, truncate (write access to configuration files) FAU_STG.11 None FAU_STG.3 Actions taken due to exceeding of a threshold. Event "log file is larger than max size" or “low on disk space” (generated by auditd); execution of administrator-specified alert action (such as file rotation, switch to single user mode, or system halt) based on the settings of the space_left_action and admin_space_left_action configuration parameters for auditd FAU_STG.4 Actions taken due to the audit storage failure. Event “no space left” or “error writing an event to disk” (generated by auditd); execution of administrator- specified alert action (such as switch to single user mode or system halt that terminates all programs capable of generating auditable events) based on the disk_full_action and disk_error_action configuration parameters for auditd FCS_CKM.1 None FCS_CKM.2 None FCS_COP.1 None FDP_ACC.1(1) None FDP_ACC.1(2) LSPP/RBAC mode None FDP_ACF.1(1) All requests to perform an operation on an object covered by the SFP. File system objects: syscalls chmod, chown, setxattr, removexattr, link, symlink, mknod, open, rename, truncate, unlink, rmdir, mount, umount Message queue objects: syscalls msgctl, msgget Semaphore objects: syscalls semget, semctl, semop, semtimedop Shared memory objects: syscalls shmget, shmctl; Details include the identity of the object. 1 The erroneous reference of CAPP/LSPP to FAU_STG.2 has been corrected in this ST. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 32 of 121 © HP, atsec 2004-2007 2007-05-31 Component Event Details (Event Names) FDP_ACF.1(2) LSPP/RBAC mode All requests to perform an operation on an object covered by the SFP. File system objects: syscalls chmod, chown, setxattr, removexattr, link, symlink, mknod, open, rename, truncate, unlink, rmdir, mount, umount Message queue objects: syscalls msgctl, msgget Semaphore objects: syscalls semget, semctl, semop, semtimedop Shared memory objects: syscalls shmget, shmctl; Details include the identity of the object. FDP_ETC.1 LSPP/RBAC mode All attempts to export information. Event: system calls connecting to external data stores: mount, accept, connect, sendto, sendmsg, open, umount FDP_ETC.2 LSPP/RBAC mode All attempts to export information. Overriding of human-readable output marking. (Additional) Event: system calls connecting to external data stores: mount, accept, connect, sendto, sendmsg, open, umount In addition, applications create audit entries (like star or the printer subsystem) FDP_IFC.1 LSPP/RBAC mode None. FDP_IFF.2 LSPP/RBAC mode All decisions on requests for information flow. Event: error codes of system calls accessing objects under the SFP are audited and indicate the decisions on information flow (either a successful system calls indicates a positive decision, whereas EACCESS or EPERM indicates a permission denial) FDP_ITC.1 LSPP/RBAC mode All attempts to import user data, including any security attributes. Event: system calls connecting to external data stores: mount, accept, connect, sendto, sendmsg, open, umount FDP_ITC.2 LSPP/RBAC mode All attempts to import user data, including any security attributes. Event: system calls connecting to external data stores: mount, accept, connect, sendto, sendmsg, open, umount In addition, applications create audit entries (like star) FDP_RIP.2 None Note 1 None FDP_UCT.1 None FDP_UIT.1 None FIA_ATD.1 None Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 33 of 121 © HP, atsec 2004-2007 2007-05-31 Component Event Details (Event Names) FIA_SOS.1 Rejection or acceptance by the TSF of any tested secret. Event USER_AUTH and USER_CHAUTHTOK (from PAM framework); details include origin of attempt (terminal or IP address as applicable) FIA_UAU.2 All use of the authentication mechanism. Event USER_AUTH and USER_CHAUTHTOK (from PAM framework) FIA_UAU.7 None FIA_UID.2 All use of the user identification mechanism, including the identity provided during successful attempts. Events USER_AUTH and USER_CHAUTHTOK(from PAM framework) FIA_USB.1 Success and failure of binding user security attributes to a subject (e.g. success and failure to create a subject). Event LOGIN (from PAM framework); syscalls fork, vfork and clone Failure: Events LOGIN (from PAM framework, failure status) FMT_MSA.1(1) All modifications of the values of security attributes. syscalls chmod, chown, setxattr, msgctl, semctl, shmctl, removexattr FMT_MSA.1(2) LSPP/RBAC mode All modifications of the values of security attributes. Event: audit message from the application load_policy and syscall open on selinuxfs files FMT_MSA.1(3) LSPP/RBAC mode All modifications of the values of security attributes. Event: audit message from the application load_policy and syscall open on selinuxfs files FMT_MSA.2 All offered and rejected values for a security attribute. Events USER_AUTH and USER_CHAUTHTOK(from PAM framework) Failure: Events LOGIN (from PAM framework, failure status) FMT_MSA.3(1) Modifications of the default setting of permissive or restrictive rules. All modifications of the initial value of security attributes. syscalls umask, open FMT_MSA.3(2) LSPP/RBAC mode Modifications of the default setting of permissive or restrictive rules. All modifications of the initial value of security attributes. Event: audit message from the application load_policy and syscall open on selinuxfs files FMT_MSA.3(3) LSPP/RBAC mode Modifications of the default setting of permissive or restrictive rules. All modifications of the initial value of security attributes. Event: audit message from the application load_policy and syscall open on selinuxfs files FMT_MTD.1(1) Audit Trail All modifications to the values of TSF data. syscalls open, rename, link, unlink, truncate (of audit log files) FMT_MTD.1(2) Audit Events All modifications to the values of TSF data. syscalls open, link, rename, truncate, unlink (of audit config files); event ”config change” FMT_MTD.1(3) User Attributes All modifications to the values of TSF data. audit text messages from “shadow- utils” trusted programs, details include new value of of the TSF data Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 34 of 121 © HP, atsec 2004-2007 2007-05-31 Component Event Details (Event Names) FMT_MTD.1(4) Authentication Data All modifications to the values of TSF data. audit text messages from “shadow- utils” trusted programs including USER_CHAUTHTOK PAM messages; attempts to bypass trusted programs detected through audited syscalls open, rename, truncate, unlink FMT_MTD.1(5) LSPP/RBAC mode All modifications to the values of TSF data, including: (i) Assignment of Users, Roles and Privileges to Roles (ii) Deletion of Users, Roles and Privileges from Roles (iii) Creation and Deletion of Roles Event: audit message from the application load_policy and syscall open on selinuxfs files FMT_MTD.3 LSPP/RBAC mode All rejected values of TSF data. Failure: Events LOGIN (from PAM framework, failure status) FMT_REV.1(1) All attempts to revoke security attributes. Event: audit text messages from “shadow-utils” trusted programs; attempts to bypass trusted programs detected through audited syscalls open, rename, truncate, unlink FMT_REV.1(2) All modifications to the values of TSF data. system calls chmod, chown, setxattr, removexattr, unlink, truncate, msgctl, semctl, shmctl FMT_SMR.2 Modifications to the group of users that are part of a role. Event: audit text messages from “shadow-utils” trusted programs “group member added”, “group member removed”, “group administrators set”, “group members set” (from trusted programs in shadow suite). FMT_SMR.2 Every use of the rights of a role. (Additional / Detailed) The user’s actions result in audited syscalls and the use of trusted programs that are audited. Details include the login ID, the origin can be determined from the associated LOGIN record for this login ID and audit session ID. FPT_AMT.1 Execution of the tests of the underlying machine and the results of the test. Event messages “amtu-*” (generated by AMTU testing tool) FPT_FLS.1 LSPP/RBAC mode Failure of the TSF. Failure: audit entries from applications managing the SELinux configuration and SELinux aware applications using libselinux: crond, login, sshd, su FPT_RCV.1 LSPP/RBAC mode Type of failure or service discontinuity. Event/Failure: audit entry because of switch between multi-user mode and single-user mode FPT_RCV.4 LSPP/RBAC mode If possible, the detection of a failure of a security function. Event/Failure: audit entry because of switch between multi-user mode and single-user mode FPT_RVM.1 None FPT_SEP.1 None FPT_STM.1 Changes to the time. Event: syscalls settimeofday, adjtimex, clock_settime. Also USYS_CONFIG messages from hwclock Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 35 of 121 © HP, atsec 2004-2007 2007-05-31 Component Event Details (Event Names) FPT_TDC.1 LSPP/RBAC mode None FPT_TST.1 LSPP/RBAC mode Execution of the TSF self tests and the results of the tests. Event: audit message from the test application FTA_LSA.1 LSPP/RBAC mode All attempts at selecting a session security attributes; Event: audit entry from an application linked against libselinux: crond, login, sshd, su FTA_TSE.1 LSPP/RBAC mode All attempts at establishment of a user session. Event: audit entry from an application linked against libselinux: crond, login, sshd, su FTP_ITC.1 All attempted uses of the trusted channel functions. Identification of the initiator and target of all trusted channel functions. Event: syscall exec (of stunnel program) Application Note: The table lists the names of the events associated with the SFR. Details of the event specific data recorded with each event are defined in the audit design documentation. 5.1.1.2 User Identity Association (FAU_GEN.2) FAU_GEN.2.1 The TSF shall be able to associate each auditable event with the identity of the user that caused the event. Application Note: The TOE maintains a “Login ID”, which is inherited by every new process spawned. This allows the TOE to identify the “real” originator of an event, regardless if he has changed his real and / or effective and filesystem user ID e. g. using the su command or executing a SUID or SGID program. 5.1.1.3 Audit Review (FAU_SAR.1) FAU_SAR.1.1 The TSF shall provide authorized administrators with the capability to read all audit information from the audit records, including: a) Date and Time of Audit Event b) The UserID responsible for the Event and optionally the role membership which enabled the user to perform the event successfully c) The access control operation and the object on which it was performed. d) The outcome of the event (success or failure) e) The User Session Identifier or Terminal Type FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. 5.1.1.4 Restricted Audit Review (FAU_SAR.2) FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access. Application Note: DAC controls ensure that only administrative users have access to the audit records. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 36 of 121 © HP, atsec 2004-2007 2007-05-31 5.1.1.5 Selectable Audit Review (FAU_SAR.3) FAU_SAR.3.1 The TSF shall provide the ability to perform searches, sorting and ordering of audit data based on the following attributes: a) User identity; b) (LSPP/RBAC mode) Subject sensitivity label; c) (LSPP/RBAC mode) Object sensitivity label; d) Date and Time of Audit event e) Object Name & type of access f) (LSPP/RBAC mode) Role that enabled the access g) (LSPP/RBAC mode) Any combination of the above items (a), (d), (e) or (f). h) group identifier (real and effective) i) event type j) outcome (success/failure) k) login from specific remote hostname l) audit id m) process id 5.1.1.6 Selective Audit (FAU_SEL.1) FAU_SEL.1.1 The TSF shall be able to include or exclude auditable events from the set of audited events based on the following attributes: a) User identity; b) Subject sensitivity label; c) Object sensitivity label; d) Object identity, user identity, subject identity, host identity, and event type e) Users belonging to a specified Role and Access types (e.g. delete, insert) on a particular object f) system call number g) directory or file name. Application Note: The TOE provides the administrator the ability to select the events to audit. This can be done by the administrator editing the filter configuration file of the audit daemon and then using the /etc/rc.d/init.d/auditd script with the ‘reload’ parameter to notify the audit daemon of the change in the configuration. The audit daemon in turn notifies the kernel of the new auditing policy. 5.1.1.7 Guarantees of Audit Data Availability (FAU_STG.1) FAU_STG.1.1 The TSF shall protect the stored audit records from unauthorized deletion. FAU_STG.1.2 The TSF shall be able to prevent modifications to the audit records. Application Note: This is achieved using the DAC controls. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 37 of 121 © HP, atsec 2004-2007 2007-05-31 5.1.1.8 Action in Case of Possible Audit Data Loss (FAU_STG.3) FAU_STG.3.1 The TSF shall generate an alarm to the authorized administrator if the audit trail exceeds a value defined in the file /etc/auditd.conf for the minimum space required for the file system the audit log file resides in. Application Note: The alarm generated by the TOE is a syslog message. This message is generated when the audit trail capacity exceeds the limit defined in the auditd.conf file. This limit can be defined by the system administrator by editing the auditd.conf file and then reloading the audit configuration. 5.1.1.9 Prevention of Audit Data Loss (FAU_STG.4) FAU_STG.4.1 The TSF shall be able to prevent auditable events, except those taken by the authorized administrator, and no other actions, if the audit trail is full. Application Note: If the audit trail gets full, the audit daemon will execute an administrator-defined action. The possible actions include a switch to single user mode or system halt, each of these will terminate all processes capable of generating auditable events. The system administrator can then back up the audit trail and make space available for the audit trail, then restart the TOE in multi-user mode. 5.1.2 Cryptographic Support (FCS) 5.1.2.1 Cryptographic key generation (SSL: Symmetric algorithms) (FCS_CKM.1(1)) FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm as defined in the SSL v3 standard and specified cryptographic key sizes 128 bit (RC4) , 168 bit (TDES), 128 bit (AES), 256 bit (AES) that meet the following: generation and exchange of session keys as defined in the SSL v3 and standard with the cipher suites defined in FCS_COP.1(2). Application Note: Generation of symmetric keys is defined in section 6.2 in the SSL v3 standard. The OpenSSL library used by the TOE also supports SSL v2, but this is seen as being not part of the evaluated configuration. The evaluation will assess that the keys are generated in accordance with the requirements defined in the SSL v3 standard. With respect to the strength of function, no assessment of the strength of the cryptographic algorithm itself and no analysis for potential weaknesses of keys with respect to the algorithm are performed. The key generation process will only be analysed and rated with respect to the entropy of the input to the key generation process and with respect to the fact that any postprocessing of this input will maintain the entropy 5.1.2.2 Cryptographic key generation (SSH: Symmetric algorithms) (FCS_CKM.1(2)) FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm as defined in the SSH v2 standard SSH Transport Layer Protocol [SSH-TRANS] and specified cryptographic key sizes 168 bit (TDES) that meet the following: generation and exchange of session keys as defined in the [SSH-TRANS] standard using the Diffie-Hellman key negotiation protocol. Application Note: For details of the key generation / key negotiation process see section 4.5, chapters 6.5, 6.6, and 7 of the SSH Transport Layer Protocol specification [SSH-TRANS] as published by the Secure Shell Charter of the Internet Engineering Task Force (IETF). The evaluation will assess that the keys are generated in accordance with the requirements defined in the [SSH-TRANS] standard, but no assessment on the strength of the keys generated will be performed as part of this evaluation. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 38 of 121 © HP, atsec 2004-2007 2007-05-31 5.1.2.3 Cryptographic key generation (SSL: RSA) (FCS_CKM.1(3)) FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm product specific and specified cryptographic key sizes 1024 bit that meet the following: not specified Application Note: The SSL v3 specification does not define how the RSA key pair is generated. This is up to the implementation. Almost all implementations of the SSL v3 standard have their own algorithm for RSA key pair generation (if they support cipher suites that use RSA). Therefore the key generation and algorithm and the standard to follow are not defined here. Only the required key size is specified. The evaluation will assess that the keys generated form a correct RSA key pair. No assessment on the strength of the keys generated will be performed as part of this evaluation. The only assessment made is with respect to the probability of the numbers used to be prime. 5.1.2.4 Cryptographic key distribution (SSL: RSA public keys) (FCS_CKM.2(1)) FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method digital certificates for public RSA keys that meets the following: certificate format as defined in the standard X.509 Version 3. Application Note: This requirement addresses the exchange of public RSA keys as part of the SSL client and server authentication. 5.1.2.5 Cryptographic key distribution (SSH: Diffie-Hellman key negotiation) (FCS_CKM.2(2)) FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method diffie-hellman-group1-sha1 that meets the following: Specification in [SSH-TRANS]. Application Note: The Diffie-Hellman protocol can be seen as a combined way to generate and distribute a shared session key between two communicating parties. So the Diffie-Hellman algorithm used by SSH is mentioned both in the key generation as well as in the key distribution security functional requirement. 5.1.2.6 Cryptographic key distribution (SSH: DSS public keys) (FCS_CKM.2(3)) FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method digital certificates for public DSS keys that meets the following: ssh-dss key format as defined in [SSH-TRANS]. 5.1.2.7 Cryptographic key distribution (SSL: Symmetric keys) (FCS_CKM.2(4)) FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method Secure Socket Layer handshake using RSA encrypted exchange of session keys that meets the following: SSL Version 3 [SSLv3]. Application Note: This requirement addresses the exchange of SSL session keys as part of the SSL handshake protocol. 5.1.2.8 Cryptographic operation (RSA) (FCS_COP.1(1)) FCS_COP.1.1 The TSF shall perform digital signature generation and digital signature verification in accordance with a specified cryptographic algorithm RSA and cryptographic key sizes 1024 bit that meet the following: SSL Version 3[SSLv3]. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 39 of 121 © HP, atsec 2004-2007 2007-05-31 Application Note: This requirement addresses the RSA digital signature generation and verification operations using the RSA algorithm as required by the SSL session establishment protocol (provided a cipher suite including RSA is used). Note that the details of the signature format such as the use of the PKCS#1 block type 1 and block type 2 are defined in the SSL Version 3 standard. 5.1.2.9 Cryptographic operation (SSL: Symmetric operations) (FCS_COP.1(2)) FCS_COP.1.1 The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm RC4, TDES and AES and cryptographic key sizes 128 bit (RC4), 168 bit (TDES), 128 bit (AES) and 256 bit (AES) that meet the following: SSL Version 3 [SSLv3] and the following cipher suites: SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, as defined in the SSL v3 standard, and TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA as defined in the IETF RFC 3268. 5.1.2.10 Cryptographic operation (SSH: Symmetric operations) (FCS_COP.1(3)) FCS_COP.1.1 The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm TDES and cryptographic key sizes 168 bit (TDES) that meet the following: SSH Version 2 [SSH-TRANS] and the following cipher suite: 3des-cbc as defined in [SSH-TANS]. 5.1.3 User Data Protection (FDP) 5.1.3.1 Discretionary Access Control Policy (FDP_ACC.1(1)) FDP_ACC.1.1 The TSF shall enforce the Discretionary Access Control Policy on processes acting on the behalf of users as subjects and file system objects (ordinary files, directories, symbolic links, device special files, UNIX Domain socket special files, named pipes), IPC objects (message queues, semaphores, shared memory segments) and all operations among subjects and objects covered by the DAC policy. 5.1.3.2 Role-based Access Control Policy (FDP_ACC.1(2)) (LSPP/RBAC mode only) FDP_ACC.1.1 The TSF shall enforce the Role-based Access Control (RBAC) SFP on: a) Subjects covered by RBAC SFP: processes b) Objects covered by RBAC SFP: file system objects and IPC objects c) All Operations on Objects covered by RBAC SFP 5.1.3.3 Discretionary Access Control Functions (FDP_ACF.1(1)) FDP_ACF.1.1 The TSF shall enforce the Discretionary Access Control Policy to objects based on the following: a) The filesystem user identity and group membership(s) associated with a subject; and b) The following access control attributes associated with an object: File system objects: POSIX ACLs and permission bits. (ACLs can be used to grant or deny access to the granularity of a single user or Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 40 of 121 © HP, atsec 2004-2007 2007-05-31 group using Access Control Entries. Those ACL entries include the standard Unix permission bits. Posix ACLs can be used for file system objects within the ext3 file system). Access rights for file system objects are: - read - write - execute (ordinary files) - search (directories) IPC objects: permission bits Access rights for IPC objects are: - read - write FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: File system objects within the ext3 file system: A subject must have search permission for every element of the pathname and the requested access for the object. A subject has a specific type access to an object if: • The subject has been granted access according to the ACL_USER_OBJ or ACL_OTHER type entry in the ACL of the object Or • The subject has been granted access by an ACL_USER, ACL_GROUP_OBJ or ACL_GROUP entry and the associated right is also granted by the ACL_MASK entry of the ACL if the ACL_MASK entry exist Or • The subject has been granted access by the ACL_GROUP_OBJ entry and no ACL_MASK entry exists in the ACL of the object. File system objects in other file systems: A subject must have search permission for every element of the pathname and the requested access for the object. A subject has a specific type access to an object if: • The subject has the filesystem userid of the owner of the object and the requested type of access is within the permission bits defined for the owner Or • The subject has not the filesystem userid of the owner of the object but the filesystem group id identical to the file system objects group id and the requested type of access is within the permission bits defined for the group Or Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 41 of 121 © HP, atsec 2004-2007 2007-05-31 • The subject has neither the filesystem userid of the owner of the object nor is the filesystem group id identical to the file system object group id and requested type of access is within the permission bits defined for "world" IPC objects: Access permissions are defined by permission bits of the IPC object. The process creating the object defines the creator, owner and group based on the userid of the current process. Access of a process to an IPC object is allowed, if • the effective userid of the of the current process is equal to the userid of the IPC object creator or owner and the „owner” permission bit for the requested type of access is set or • the effective userid of the current process is not equal to the userid of the IPC object creator or owner and the effective group id of the current process is equal to the group id of the IPC object and the „group” permission bit for the requested type of access is set or • The „world” permission bit for the requested type of access is set for users that do not satisfy one of the first two conditions FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: File System Objects: A process with a user ID of 0 is known as a root user process. These processes are generally allowed all access permissions. But if a root user process requests execute permission for a program (as a file system object), access is granted only if execute permission is granted to at least one user. IPC objects: A process with a user ID of 0 is known as a root user process. These processes are generally allowed all access permissions. FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following rules: Write access to file system objects other than device special files on a file system mounted as read-only is always denied. Write access to a file marked as immutable is always denied. Application note: The TOE includes functionality that can add additional restrictions, this ST does not make any claims about these additional checks. 5.1.3.4 Role-based Access Control Functions (FDP_ACF.1(2)) (LSPP/RBAC mode only) FDP_ACF.1.1 The TSF shall enforce the RBAC SFP to objects based on the following user attributes: a) User Identity b) Authorized Roles for the User (refer to Glossary for definition) The TSF shall enforce the RBAC SFP to objects based on the following subject attributes: a) Subject Identity b) Role(s) which can invoke the subject Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 42 of 121 © HP, atsec 2004-2007 2007-05-31 The TSF shall enforce the RBAC SFP to objects based on the following object attributes: a) Object Identity b) Operations permitted on the objects for various Roles FDP_ACF.1.2 The TSF shall enforce the following rules to determine if any operation among controlled subjects and controlled objects is allowed: The subject invoking the operation on an object is assigned to a role whose privilege set includes the operation on the object. FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: Allow an access operation by a subject on an object only if the user associated with the subject belongs to a role that permits the access operation on the object. FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the user associated with the subject not belonging to any role that permits the requested access operation on the object. 5.1.3.5 Export of unlabeled user data (FDP_ETC.1) (LSPP/RBAC mode only) FDP_ETC.1.1 The TSF shall enforce the Mandatory Access Control Policy when exporting unlabeled user data, controlled under the MAC policy, outside the TSF Scope of Control (TSC). FDP_ETC.1.2 The TSF shall export the unlabeled user data without the user data’s associated security attributes. Note6 The TSF shall enforce the following rules when unlabeled user data is exported from the TSC: a) devices used to export data without security attributes cannot be used to export data with security attributes unless the change in device state is performed manually and is auditable; b) none. 5.1.3.6 Export of labeled user data (FDP_ETC.2) (LSPP/RBAC mode only) FDP_ETC.2.1 The TSF shall enforce the Mandatory Access Control Policy when exporting labeled user data, controlled under the MAC policy, outside the TSC. FDP_ETC.2.2 The TSF shall export the labeled user data with the user data’s associated security attributes. FDP_ETC.2.3 The TSF shall ensure that the security attributes, when exported outside the TSC, are unambiguously associated with the exported labeled user data. FDP_ETC.2.4 The TSF shall enforce the following rules when labeled user data is exported from the TSC: a) when data is exported in a human-readable or printable form: • the authorized administrator shall be able to specify the printable label that is assigned to the sensitivity label associated with the data. • each print job shall be marked at the beginning and end with the printable label assigned to the “least upper bound” sensitivity label of all the data exported in the print job. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 43 of 121 © HP, atsec 2004-2007 2007-05-31 • each page of printed output shall be marked with the printable label assigned to the “least upper bound” sensitivity label of all the data exported to the page. By default, this marking shall appear on both the top and bottom of each printed page. b) devices used to export data with security attributes cannot be used to export data without security attributes unless the change in device state is performed manually and is auditable; c) devices used to export data with security attributes shall completely and unambiguously associate the security attributes with the corresponding data; d) none. Application note: Labeled data can be exported using the star utility, which will keep the labels attached to file system objects, as it preserves the extended file attributes 5.1.3.7 Mandatory access control policy (FDP_IFC.1) (LSPP/RBAC mode only) FDP_IFC.1.1 The TSF shall enforce the Mandatory Access Control Policy on processes acting on behalf of users as subjects, file system objects and IPC objects as objects, and all operations among subjects and objects covered by the MAC policy. 5.1.3.8 Mandatory access control functions (FDP_IFF.2) (LSPP/RBAC mode only) FDP_IFF.2.1 The TSF shall enforce the Mandatory Access Control Policy based on the following types of subject and information security attributes: a) the sensitivity label of the subject; and b) the sensitivity label of the object containing the information. Sensitivity label of subjects and objects shall consist of the following: • a hierarchical level; and • a set of non-hierarchical categories. FDP_IFF.2.2 The TSF shall permit an information flow between a controlled subject and controlled information through a controlled operation if the following rules, based on the ordering relationships between security attributes, hold: a) if the sensitivity label of the subject is greater than or equal to the sensitivity label of the object, the flow of information from the object to the subject is permitted (a read operation); b) if the sensitivity label of the object is greater than or equal to the sensitivity label of the subject; the flow of information from the subject to the object is permitted (a write operation); c) if the sensitivity label of subject A is greater than or equal to the sensitivity label of subject B; the flow of information from subject B to subject A is permitted. FDP_IFF.2.3 The TSF shall enforce the: none FDP_IFF.2.4 The TSF shall provide the following: none FDP_IFF.2.5 The TSF shall explicitly authorize an information flow based on the following rules: a user is permitted to bypass the information flow policy, if the subject holds a MAC override privilege for the requested operation and object type. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 44 of 121 © HP, atsec 2004-2007 2007-05-31 Application note: All MAC override privileges are assigned to the security administrator role and to some restore and installation utilities like rpm. FDP_IFF.2.6 The TSF shall explicitly deny an information flow based on the following rules: none FDP_IFF.2.7 The TSF shall enforce the following relationships for any two valid sensitivity labels: a) there exists an ordering function that, given two valid sensitivity labels, determines if the sensitivity labels are equal, if one sensitivity label is greater than the other, or if the sensitivity labels are incomparable; and • sensitivity labels are equal if the hierarchical level of both labels are equal and the non-hierarchically category sets are equal. • sensitivity label A is greater than sensitivity label B if one of the following conditions exists: ƒ if the hierarchical level of A is greater than the hierarchical level of B, and the non-hierarchical category set of A is equal to the non-hierarchical category set of B. ƒ if the hierarchical level of A is equal to the hierarchical level of B, and the non-hierarchical category set of A is a proper super- set of the nonhierarchical category set of B. ƒ if the hierarchical level of A is greater than the hierarchical level of B, and the non-hierarchical category set of A is a proper2 superset of the nonhierarchical category set of B. • sensitivity labels are incomparable if they are not equal and neither label is greater than the other. b) there exists a “least upper bound” in the set of sensitivity labels, such that, given any two valid sensitivity labels, there is a valid sensitivity label that is greater than or equal to the two valid sensitivity labels; and c) there exists a “greatest lower bound” in the set of the sensitivity labels, such that, given any two valid sensitivity labels, there is a valid sensitivity label that is not greater than the two valid sensitivity labels. 5.1.3.9 Import of unlabeled user data (FDP_ITC.1) (LSPP/RBAC mode only) FDP_ITC.1.1 The TSF shall enforce the Mandatory Access Control Policy when importing unlabeled user data, controlled under the MAC policy, from outside the TSC. FDP_ITC.1.2 The TSF shall ignore any security attributes associated with the unlabeled user data when imported from outside the TSC. FDP_ITC.1.3 The TSF shall enforce the following rules when importing unlabeled user data controlled under the MAC policy from outside the TSC: a) devices used to import data without security attributes cannot be used to import data with security attributes unless the change in device state is performed manually and is auditable. b) none. Application note: See the application note on FDP_ETC.1 for export of unlabeled data. 2 The word “proper” in this rule has been taken from LSPP, but is definitively wrong in this rule. Because the hierarchical level of A is already greater than the hierarchical level of B, A is greater than B even if the sets of categories of A and B are identical Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 45 of 121 © HP, atsec 2004-2007 2007-05-31 The requirement also applies for the import of RSA key pairs or Diffie-Hellman key pairs imported to be used for the cryptographic operations of the TOE. The administrators need to ensure using the MAC and DAC policy enforced by the TOE that this key material is imported in a secure way and can not be imported by unauthorized users. 5.1.3.10 Import of labeled user data (FDP_ITC.2) (LSPP mode only) FDP_ITC.2.1 The TSF shall enforce the Mandatory Access Control Policy when importing labeled user data, controlled under the MAC policy, from outside the TSC. FDP_ITC.2.2 The TSF shall use the security attributes associated with the imported labeled user data. FDP_ITC.2.3 The TSF shall ensure that the protocol used provides for the unambiguous association between security attributes and the labeled user data received. FDP_ITC.2.4 The TSF shall ensure that interpretation of the security attributes of the imported labeled user data is as intended by the source of the user data. FDP_ITC.2.5 The TSF shall enforce the following rules when importing labeled user data controlled under the MAC policy from outside the TSC: a) devices used to import data with security attributes cannot be used to import data without security attributes unless the change in device state is performed manually and is auditable; b) none. c) sensitivity label, consisting of the following: • a hierarchical level; and • a set of non-hierarchical categories. Application note: See the application note on FDP_ETC.2 for export of labeled data. 5.1.3.11 Object Residual Information Protection (FDP_RIP.2) FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to all objects. 5.1.3.12 Subject Residual Information Protection (Note 1) NOTE 1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to all subjects. 5.1.3.13 Basic data exchange confidentiality (FDP_UCT.1) FDP_UCT.1.1 The TSF shall enforce the Discretionary Access Control Policy and the Mandatory Access Control Policy to be able to transmit and receive objects in a manner protected from unauthorised disclosure. Application Note: Confidentiality of data during transmission is ensured when the one of the secured protocols ssh, or ssl are used. User processes are still bound by the discretionary access control policy with respect to the data they are able to transfer. The TOE is able act both as a server and a client for ssh, ssl, or IPSec connections. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 46 of 121 © HP, atsec 2004-2007 2007-05-31 5.1.3.14 Data exchange integrity (FDP_UIT.1) FDP_UIT.1.1 The TSF shall enforce the Discretionary Access Control Policy Policy and the Mandatory Access Control Policy to be able to transmit and receive user data in a manner protected from modification and insertion errors. FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data, whether modification or insertion has occurred. Application Note: Integrity of data during transmission is ensured when the one of the secured protocols ssh, ssl, or IPSec are used. User processes are still bound by the discretionary access control policy with respect to the data they are able to transfer. The TOE is able act both as a server and a client for ssh, ssl, or IPSec connections. 5.1.4 Identification and Authentication (FIA) 5.1.4.1 User Attribute Definition (FIA_ATD.1) FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: a) User Identifier; b) Group Memberships; c) Authentication Data; d) (LSPP/RBAC mode) User Clearance; e) (LSPP/RBAC mode) List of Authorized Roles; f) (LSPP/RBAC mode) SELinux user identity; g) (LSPP/RBAC mode) Default login security context. 5.1.4.2 Strength of Authentication Data (FIA_SOS.1) FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet the following: a) For each attempt to use the authentication mechanism, the probability that a random attempt will succeed is less than one in 1,000,000; b) For multiple attempts to use the authentication mechanism during a one minute period, the probability that a random attempt during that minute will succeed is less than one in 100,000; and c) Any feedback given during an attempt to use the authentication mechanism will not reduce the probability below the above metrics. 5.1.4.3 Authentication (FIA_UAU.2) FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Application Note: Untrusted processes running on behalf of a normal user may use network functions to import and export data they have access to. This process may therefore export user data without authenticating or even knowing the identity of a user receiving such data. This is not considered to be a violation of the security policy with respect to identification and authentication and discretionary access control, since it is well-known that discretionary access control can not control flow of information. An example of such an export function is a user process running a Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 47 of 121 © HP, atsec 2004-2007 2007-05-31 web-server on an unprivileged port. Still this process is limited in its access by the security policy of the TOE. 5.1.4.4 Protected Authentication Feedback (FIA_UAU.7) FIA_UAU.7.1 The TSF shall provide only obscured feedback to the user while the authentication is in progress. 5.1.4.5 Identification (FIA_UID.2) FIA_UID.2.1 The TSF shall require each user to identify itself before allowing any other TSF-mediated actions on behalf of that user. 5.1.4.6 User-Subject Binding (FIA_USB.1) FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: a) The user identity which is associated with auditable events; b) The user identity or identities which are used to enforce the Discretionary Access Control Policy. c) The group membership or memberships used to enforce the Discretionary Access Control Policy. d) (LSPP/RBAC mode) The sensitivity label used to enforce the Mandatory Access Control Policy, which consists of the following: • A hierarchical level; and • A set of non-hierarchical categories. e) (LSPP/RBAC mode) The Active Role set used to enforce the Role-based Access Control Policy as a subset of the Authorized Roles for the User. FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of a user: a) Upon successful identification and authentication, the login user ID, the real user ID, the filesystem user ID, and the effective user ID shall be those specified in the user entry for the user that has authenticated successfully. b) Upon successful identification and authentication, the real group ID, the filesystem group ID, and the effective group ID shall be those specified via the group membership attribute in the user entry. c) (LSPP/RBAC mode) The sensitivity label associated with a subject shall be within the clearance range of the user. d) (LSPP/RBAC mode) The Active Role Set chosen during a login operation must be a subset of the Authorized Roles for the User. FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of a user: a) The effective and filesystem user ID of a user can be changed by the use of an executable with the setuid bit set. In this case the program is executed with the effective and filesystem user ID of the program owner. Access rights are then evaluated using the filesystem user ID of the program owner. The real and login user ID remain unchanged. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 48 of 121 © HP, atsec 2004-2007 2007-05-31 b) The effective, filesystem, and real user ID of a user can be changed by the su command. In this case the real, filesystem, and effective user ID of the user is changed to the user specified in the su command (provided authentication is successful). The login user ID remains unchanged. c) The filesystem and effective group ID of a user can be changed by the use of an executable with the setgid bit set. In this case the program is executed with the filesystem and effective group ID of the program owner. Access rights are then evaluated using the filesystem group ID of the program owner. d) (LSPP/RBAC mode) The active role of a subject can be changed if a transition rule for the requested change is defined and a allow rule for the requested transition is defined. e) (LSPP/RBAC mode) The sensitivity label of a subject can be changed if a transition rule for the requested change is defined and a allow rule for the requested transition is defined. 5.1.5 Security Management (FMT) 5.1.5.1 Management of Object Security Attributes (FMT_MSA.1(1)) FMT_MSA.1.1 The TSF shall enforce the Discretionary Access Control Policy to restrict the ability to modify the access control attributes associated with a named object to authorized administrators and the owner of the object. For IPC objects also the original creator of the object has the ability to modify the access control attributes. Application Note (LSPP/RBAC mode): authorized administrators are administrative users in the sysadm_r role 5.1.5.2 Management of object security attributes for MAC (FMT_MSA.1(2)) (LSPP/RBAC mode only) FMT_MSA.1.1 The TSF shall enforce the Mandatory Access Control Policy to restrict the ability to modify the sensitivity label associated with an object to the security administrator. 5.1.5.3 Management of User Security Attributes (FMT_MSA.1(3)) (LSPP/RBAC mode only) FMT_MSA.1.1 The TSF shall enforce the RBAC SFP to restrict the ability to modify, delete, create instances of the following user security attribute to a set of RBAC Administrative Roles: a) User Role Authorizations FMT_MSA.1.1 The TSF shall enforce the RBAC SFP to restrict the ability to create, modify the composition of the following user security attribute to a set of RBAC Administrative Roles: a) Default Active Role Set (refer to Glossary for definition) FMT_MSA.1.1 The TSF shall enforce the RBAC SFP to restrict the ability to modify the composition of the following session security attribute to session owner: a) Active Role set for a user (refer to Glossary for definition) FMT_MSA.1.1 The TSF shall enforce the RBAC SFP to restrict the ability to modify the object security attributes to (i) Object Owners and (ii) Set of RBAC Administrative Roles. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 49 of 121 © HP, atsec 2004-2007 2007-05-31 5.1.5.4 Secure security attributes (FMT_MSA.2) FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for security attributes. Application Note: This SFR addresses several issues: It fulfils a dependency for FCS_CKM.1, FCS_CKM.2, and FCS_COP.1. The assessment with respect to this requirement in the evaluation of this TOE does not include any assessment of the cryptographic strength of the keys generated or used. Instead the assessment with respect to this requirement just includes an assessment that the TOE protects those keys from unauthorized access, disclosure or tampering. LSPP/RBAC mode only: It is also required by [RBACPP]; as such it addresses the ability of the system to enforce sufficiently strong passwords by applying password complexity rules to new passwords, and to reject illegal values for certain security attributes. 5.1.5.5 Static Attribute Initialization for DAC (FMT_MSA.3(1)) FMT_MSA.3.1 The TSF shall enforce the Discretionary Access Control Policy to provide restrictive default values for security attributes that are used to enforce the SFP. 3 FMT_MSA.3.2 The TSF shall allow an authorized administrators and the owner of the object to specify alternative initial values to override the default values when an object or information is created. Application note: Because the option to assign a property other than “restrictive” or “permissive” was only introduced with final interpretation RI#202, the authors of LSPP and CAPP have selected “restrictive”, but allowed an authorized administrator to override those default values. In reality, most systems will neither define the “restrictive” nor the “permissive” case as the default value, but the default values will be defined such that they match the intended operational policy in the best way. This also applies to 5.1.5.6. 5.1.5.6 Static Attribute Initialization for MAC (FMT_MSA.3(2)) (LSPP/RBAC mode only) FMT_MSA.3.1 The TSF shall enforce the Mandatory Access Control Policy to provide restrictive default values for security attributes that are used to enforce the SFP.3 FMT_MSA.3.2 The TSF shall allow the authorized administrator to specify alternative initial values to override the default values when an object or information is created. 5.1.5.7 Static Attribute Initialization for RBAC (FMT_MSA.3(3)) (LSPP/RBAC mode only) FMT_MSA.3.1 The TSF shall enforce the RBAC SFP to provide the following default values for object security attributes that are used to enforce the SFP: a) At creation time, an object is assigned a security context (SELinux user identity, role, type, sensitivity label) as defined in the transformation rules of the currently loaded policy. FMT_MSA.3.2 The TSF shall allow the following roles to specify alternative initial values to override the default values when an object or information is created: a) Set of RBAC Administrative Roles 3 [CAPP] and [LSPP] refined the term „SFP“ to „Discretionary Access Control SFP“ and „Mandatory Access Control SFP“, respectively, interpreting a formatting error in previous CC versions as a requirement to instantiate the term SFP here. Since the formatting has been corrected in [CC], this instantiation has been removed in favor of more strict CC compliance. However, the title and wording of the SFRs clearly express that the restrictive default values only apply to the DAC and MAC SFP, respectively. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 50 of 121 © HP, atsec 2004-2007 2007-05-31 5.1.5.8 Management of the Audit Trail (FMT_MTD.1(1)) FMT_MTD.1.1 The TSF shall restrict the ability to create, delete, and clear the audit trail to authorized administrators. Application Note: This requirement is implemented using the discretionary access control features of the TOE to protect the files holding the audit trail. 5.1.5.9 Management of Audited Events (FMT_MTD.1(2)) FMT_MTD.1.1 The TSF shall restrict the ability to modify or observe the set of audited events to authorized administrators. Application Note: This requirement is implemented using the discretionary access control features of the TOE to protect the audit configuration files. In LSPP/RBAC mode, the authorized administrator is a user in the security administrator role. 5.1.5.10 Management of User Attributes (FMT_MTD.1(3)) FMT_MTD.1.1 The TSF shall restrict the ability to initialize and modify the user security attributes, other than authentication data, to authorized administrators. 5.1.5.11 Management of Authentication Data (FMT_MTD.1(4)) FMT_MTD.1.1 The TSF shall restrict the ability to initialize the authentication data to authorized administrators. FMT_MTD.1.1 The TSF shall restrict the ability to modify the authentication data to the following: a) authorized administrators; and b) users, which are allowed to modify their own authentication data 5.1.5.12 Management of RBAC TSF Data (FMT_MTD.1(5)) (LSPP/RBAC mode only) FMT_MTD.1.1 The TSF shall restrict the ability to modify, create the following list of TSF Data to a set of RBAC Administrative Roles: a) Role Definitions & Role Attributes b) Role Hierarchies (by assigning one or more roles to other roles) c) Constraints among Role Relationships Application Note: [RBACPP] also lists (a) all user passwords, and (e) list auf auditable events; (a) is already covered by FMT_MTD.1(4), and (e) by FMT_MTD.1(2). therefore, these list items have not been repeated here. 5.1.5.13 Secure TSF Data (FMT_MTD.3) (LSPP/RBAC mode only) FMT_MTD.3.1 The TSF shall ensure that only secure values are accepted for TSF data. Application Note: This SFR applies to the enforcement of quality metrics for passwords. 5.1.5.14 Revocation of User Attributes (FMT_REV.1(1)) FMT_REV.1.1 The TSF shall restrict the ability to revoke security attributes associated with the users within the TSC to authorized administrators. FMT_REV.1.2 The TSF shall enforce the rules: Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 51 of 121 © HP, atsec 2004-2007 2007-05-31 a) The immediate revocation of security-relevant authorizations; and b) Revocations/modifications made by an authorized administrator to security attributes of a user such as the user identifier, user name, user group(s), user password or user login shell shall be effective the next time the user logs in. Application Note: Like other UNIX type operating systems also the TOE does not enforce “immediate revocation” for user security attributes. To achieve this, the system administrator has to check, if the user whose security attributes have been changed is currently logged in. If this is the case, the system administrator has to “force” the user to log off as indicated in the Application Note in [LSPP] and [CAPP]. 5.1.5.15 Revocation of Object Attributes (FMT_REV.1(2)) FMT_REV.1.1 The TSF shall restrict the ability to revoke security attributes associated with objects within the TSC to users authorized to modify the security attributes by the Discretionary Access Control Policy or (in LSPP/RBAC mode) the Mandatory Access Control Policiy and the Role-based Access Control Policy. FMT_REV.1.2 The TSF shall enforce the rules: a) the access rights associated with an object shall be enforced when an access check is made; b) (LSPP/RBAC mode) the rules of the mandatory access control policy are enforced on all future operations; c) Access rights to file system and IPC objects are checked when the object is opened. Revocations of access rights for file system objects become effective the next time a user affected by the revocation tries to open a file system object or IPC object. Application Note: Like most other UNIX type operating systems the TOE implements delayed revocation as indicated in the CAPP/LSPP Application Note. 5.1.5.16 Specification of Management Functions (FMT_SMF.1) FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions: y Object security attributes management y User attribute management y Authentication data management y Audit event management Application Note: This security functional requirement is not included in the protection profiles and was added because a dependency from FMT_MSA.1 and FMT_MTD.1 to this new component has been defined in [CC]. 5.1.5.17 Security Roles (FMT_SMR.2) FMT_SMR.2.1 The TSF shall maintain the following roles: a) authorized administrator; in LSPP/RBAC mode, these are administrative users assigned to RBAC Administrative Roles: ƒ (LSPP/RBAC mode) system administrator ƒ (LSPP/RBAC mode) security administrator b) Roles for Object Owners: users authorized by the Discretionary Access Control Policy to modify object security attributes; Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 52 of 121 © HP, atsec 2004-2007 2007-05-31 c) (LSPP/RBAC mode) users authorized by the Mandatory Access Control Policy to modify object security attributes; d) users authorized to modify their own authentication data; and e) no other roles FMT_SMR.2.2 The TSF shall be able to associate users with roles. FMT_SMR.2.3 (LSPP/RBAC mode) The TSF shall ensure that the following conditions for (a) Roles of Object Owners and (b) the set of RBAC Administrative Roles are satisfied: a) Object Owners can modify security attributes for only the objects they own b) The set of RBAC Administrative Roles can modify security attributes for all objects under the control of the TOE. Application Note: The role model supported by the TOE in CAPP mode is a very simple one: the administrative user is root (extended to all members of the “wheel” group that may su to root). All other users of the system have the user role. As users, they may own certain objects, letting them assume the Owner role for these objects. In LSPP/RBAC mode, administrative powers are split into different roles as defined by the SELinux policy. By default roles for the system administrator, security administrator, and ordinary users are installed. 5.1.6 Protection of the TOE Security Functions (FPT) 5.1.6.1 Abstract Machine Testing (FPT_AMT.1) FPT_AMT.1.1 The TSF shall run a suite of tests at the request of an authorized administrator to demonstrate the correct operation of the security assumptions provided by the abstract machine that underlies the TSF. Application Note: The abstract machine testing tool will be platform dependent. Chapter 6 describes the common feature of all those tools. 5.1.6.2 Failure with preservation of Secure State (FPT_FLS.1 )(LSPP/RBAC mode only) FPT_FLS.1.1 The TSF shall preserve a secure state when the following failures occur: a) The entire RBAC database containing data on Privileges assigned to a role, Users authorized for a role, Role constraints and relationships or some specific tables containing subsets of these data are off-line, corrupt or inaccessible. 5.1.6.3 Manual Recovery (FPT_RCV.1) (LSPP/RBAC mode only) FPT_RCV.1.1 After a failure or service discontinuity, the TSF shall enter a maintenance mode where the ability to return the TOE to a secure state is provided. 5.1.6.4 Function Recovery (FPT_RCV.4) (LSPP/RBAC mode only) FPT_RCV.4.1 The TSF shall ensure that the following SFs and failure scenarios have the property that the SF either completes successfully, or for the indicated failure scenarios, recovers to a consistent and secure state: a) The SF that checks whether a specified privilege is assigned to any role but the database containing the privilege data is not on-line or the particular data table is inaccessible. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 53 of 121 © HP, atsec 2004-2007 2007-05-31 b) The SF that checks whether a specified role has been assigned to a particular user but the database containing the role membership information is not on-line or the particular data table is inaccessible. c) no other scenarios 5.1.6.5 Reference Mediation (FPT_RVM.1) FPT_RVM.1.1 The TSF shall ensure that the TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed. 5.1.6.6 Domain Separation (FPT_SEP.1) FPT_SEP.1.1 The TSF shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects. FPT_SEP.1.2 The TSF shall enforce separation between the security domains of subjects in the TSC. Application Note: The TOE enforces this requirement by using the address separation features provided by the Memory Management Units and the protection offered by a multi-state CPU. Although the TOE operates on three different platforms, all those platforms have in common a Memory Management Unit allowing to define address space separation between trusted and untrusted subjects and all platforms support a multi-state CPU where modification to the address space definition and direct access to peripheral devices and the CPU configuration can be restricted to a state reserved for a defined part of the TSF (the kernel). The TOE ensures that those features are used correctly to prohibit any untrusted subject from unallowed interference and tampering with the TSF. 5.1.6.7 Reliable Time Stamps (FPT_STM.1) FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use. Application Note: The TOE uses a hardware timer to maintain its own time stamp. This hardware timer is protected from tampering by untrusted subjects. The start value for this timer may be set by the system administrator, but the system administrator may also start a program that uses an external trusted time source to set this initial value. 5.1.6.8 Inter-TSF basic TSF data consistency (FPT_TDC.1) (LSPP mode only) FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret sensitivity labels associated with subjects or objects when shared between the TSF and another trusted IT product. FPT_TDC.1.2 The TSF shall use the rules and attributes defined in the MAC SFP when interpreting the TSF data from another trusted IT product. Application note: This requirement is required as a dependency from FDP_ITC.2. Although FDP_ITC.2 is included in LSPP, this dependency has been neither resolved nor has been any rationale provided as to why this dependency does not apply for LSPP. Because the authors of this Security Target do not have access to the evaluation technical report of the LSPP evaluation, the authors of this Security Target do not know if there was a reason for not resolving this dependency. The authors of this Security Target would have expected in any case that the rationale in LSPP provide an explanation why the dependency has not been resolved. Inter-TSF data consistency shall ensure that sensitivity labels are consistently interpreted when this information is shared between different instantiations of the TOE or when UNIX file system objects with their extended attributes are exported from one system and imported into another system. In order to do this, the definition of the sensitivity labels between the systems involved have to be identical. It is anticipated that the Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 54 of 121 © HP, atsec 2004-2007 2007-05-31 administrators of the cooperating system share the required definitions. There is no automated mechanism (like a central security database) foreseen to achieve this. 5.1.6.9 TSF Self Test (FPT_TST.1) (LSPP/RBAC mode only) FPT_TST.1.1 The TSF shall run a suite of self tests at the request of the authorised user to demonstrate the correct operation of the TSF. FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity of TSF data. FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code. 5.1.7 TOE Access (FTA) 5.1.7.1 Limitation on Scope of Selectable Attributes (FTA_LSA.1) (LSPP/RBAC mode only) FTA_LSA.1.1 The TSF shall restrict the scope of the session security attributes (Active Role Set for the User) based on the set of Authorized Roles for the User. 5.1.7.2 TOE Session Establishment (FTA_TSE.1) (LSPP/RBAC mode only) FTA_TSE.1.1 The TSF shall be able to deny session establishment based on the default active role set for the user being empty. 5.1.8 Trusted Path/Channels (FTP) 5.1.8.1 Inter-TSF trusted channel (FTP_ITC.1) FTP_ITC.1.1 The TSF shall provide a communication channel between itself and a remote trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure. FTP_ITC.1.2 The TSF shall permit the TSF or the remote trusted IT product to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for when the communication uses the SSH v2 or SSL v3 protocol offered as services by the TOE. 5.1.9 Strength of Function The claimed minimum strength of function is SOF-medium. Note: The security function within the TOE that uses a permutational or probabilistic mechanism is the authentication function that uses passwords. No strength of function analysis is performed for the cryptographic algorithms themselves which also excludes any analysis of the existence and characterization of cryptographically weak keys.. This statement is made in compliance with part 1 of the CC and paragraph 414 of part 2 of the CEM. 5.2 TOE Security Assurance Requirements The target evaluation assurance level for the product is EAL4 [CC] augmented by ALC_FLR.3. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 55 of 121 © HP, atsec 2004-2007 2007-05-31 5.3 Security Requirements for the IT Environment No security functional requirements for the IT environment are applicable, because all security functions are completely implemented without any support from the IT environment. 5.4 Security Requirements for the Non-IT Environment All the security objectives for the TOE environment address physical protection of the TOE or procedures that need to be obeyed by administrative users. Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 56 of 121 © HP, atsec 2004-2007 2007-05-31 6 TOE Summary Specification 6.1 Security Enforcing Components Overview 6.1.1 Introduction This chapter describes the security functions of Red Hat Enterprise Linux that are subject to this evaluation. A large subset of the overall security related functions of Red Hat Enterprise Linux has been included in this evaluation. Those functions provide the basic security for a server within a protected environment. They allow for identification and authentication of users, access control to files and IPC objects, auditing of security critical events and the secure communication with other trusted systems. The TOE protects the security functions from unauthorized tampering and bypassing and allows only administrative users to manage the security functions. Normal users are only allowed to manage access control rights of the file system and IPC objects they own and to modify their own password in accordance with the password rules enforced by the TOE. All other system administration tasks can only be performed by administrative users. In LSPP/CAPP mode, privileges required to perform administrative tasks have been grouped to certain roles to which administrative users can be assigned. In CAPP mode, all privileges are concentrated in the superuser account.Those functions are required as a basis for application level security functions and mechanisms and can be used to build application-specific security policies. 6.1.2 SELinux The major difference between the CAPP mode of operation and the LSPP/RBAC mode of operation is the activation of the SELinux enhancements with the strict policy which includes MLS restrictions in the latter mode. CAPP mode allows SELinux to be enabled with a policy that does not restrict the capabilities of root, like the targeted policy. This section discusses the basic architecture and the policies implemented by SELinux using the strict policy for LSPP mode. 6.1.2.1 SELinux architecture and implementation Security-enhanced Linux (SELinux) is an implementation of a mandatory access control mechanism. This mechanism is in the Linux kernel, checking for allowed operations after standard Linux discretionary access controls are checked. SELinux is implemented in the Linux kernel using the LSM (Linux Security Modules) framework. To support fine-grained access control, SELinux implements two technologies: Type Enforcement™ (TE) and a kind of role-based access control (RBAC) Mandatory and role-based access control using type enforcement is described in Figure 1: Red Hat Enterprise Linux 5 Security Target for CAPP, LSPP and RBAC compliance Page 57 of 121 © HP, atsec 2004-2007 2007-05-31 Figure 1: SELinux architecture A request of a subject (process) to peform an operation (like open, create, write) on an object is routed to the SELinux policy enforcement server, which gathers the security contexts of the subject object and and routes the information to the security server, which and consults the policy database whether the requested operation is allowed or not. The security server provides its decision back to the policy enforcement server, which then enforces this decision by allowing or denying the operation. By separating the security server and its policy database from the policy enforcement server, a variety of policies can be defined without changing the kernel code. For performance reasons, policy decisions are cached in the access vector cache (AVC). All servers are part of the operating system kernel. Security contexts are a set of four security attributes associated with a process or an object: user An SELinux user account associated with a subject (denoting the the user on whose behalf the process is executing) or object (the object owner). Note that SELinux user identities are different from the user IDs in the Linux password database. role Users are authorized to one or more roles, each of which defines a set of privileges or permissions a user can be granted. Every subject can be in only one role at any given time. Transition between roles is accomplished with the newrole command, which is somewhat similar to the su command for changing Linux user IDs. type Types (the term is used interchangeably with the term domains) divide subjects and objects into related groups. A type or domain can be thought of as a name for a sandbox in which processes with similar security characteristics execute and in which certain objects are available to them. Currently, over 150 types are defined by a default SELinux installation. label a sensitivity label consists of a sensitivity range and a set of categories. the TOE provides support for 16 sensitivity levels (s0 to s15) and 256 categories (c0 to c255) Security contexts have the format of :::