{"product_id":10338,"v_id":10338,"product_name":"Red Hat Enterprise Linux Ver. 5.3 on Dell 11G Family Servers","certification_status":"Not Certified","certification_date":"2009-12-23T00:12:00Z","tech_type":"Operating System","vendor_id":{"name":"Dell Technologies Inc.","website":"https://www.dell.com/"},"vendor_poc":"Jack Lau","vendor_phone":"512-728-4660","vendor_email":"Jack_Lau@Dell.com","assigned_lab":{"cctl_name":"atsec information security corporation"},"product_description":"<p>The target of evaluation (TOE) is the operating system Red Hat Enterprise Linux Version 5.3. The TOE is a general purpose; multi-user, multi-tasking Linux based operating system, which provides a platform for a variety of applications. The evaluation covers a potentially distributed, but closed network of Dell 11th Generation PowerEdge servers running the evaluated version of Red Hat Enterprise Linux and also includes the evaluated version of Red Hat Enterprise Linux running under Xen on the Dell 11th Generation PowerEdge servers<strong>. </strong>The hardware platforms selected for the evaluation consist of machines which are available when the evaluation was completed and are expected to remain available for a substantial period of time afterwards.</p>\r\n<p>&nbsp;</p>\r\n<p>The TOE Security Functions (TSF) consist of operating system functions that run in kernel mode plus some trusted processes. These are the functions that enforce the security policy as defined in the Security Target. Tools and commands executed in user mode that are used by an administrative user must also be trusted to manage the system in a secure way. The basic tools required for the secure configuration and management of the TOE are included as part of the TSF in this evaluation.</p>\r\n<p>&nbsp;</p>\r\n<p>&nbsp;</p>\r\n<p>&nbsp;</p>\r\n<p>&nbsp;</p>","evaluation_configuration":null,"security_evaluation_summary":"<p>The Red Hat Enterprise Linux Version 5.3 was evaluated against the Common Criteria for Information Technology Security Evaluation, Version 3.1, by the atsec information security corporation Common Criteria Testing Laboratory (CCTL). The evaluation methodology used was the Common Methodology for Information Technology Security Evaluation, Version 3.1. The CCTL concluded that the TOE Common Criteria Part 2 extended and Part 3 conformant, with a claimed Evaluation Assurance Level of EAL4 augmented by ALC_FLR.3. The validation was conducted by NIAP&trade;s Common Criteria Evaluation and Validation Scheme (CCEVS).</p>","environmental_strengths":"<p>Red Hat Enterprise Linux provides the security functionality to meet the Controlled Access Protection Profile requirements. The following are the security features available:</p>\r\n<p>&nbsp;</p>\r\n<p><strong>Identification and Authentication:</strong> The TOE 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 the TOE. Functions ensure a basic password strength, limit the use of the su command and restrict root login to specific terminals are also included.&nbsp; Other authentication methods (e. g. Kerberos authentication, token based authentication) that are supported by the TOE as pluggable authentication modules are not part of the evaluated configuration.</p>\r\n<p>&nbsp;</p>\r\n<p><strong>Audit:</strong> The TOE provides the capability to audit a large number of events including individual system calls as well as events generated by trusted processes. Audit data is collected in regular files in ASCII format. The TOE provides a program for the purpose of searching the audit records. The system administrator can define a rule base to restrict auditing to the events he is interested in. This includes the ability to restrict auditing to specific events, specific users, specific objects or a combination of any of these.</p>\r\n<p>&nbsp;</p>\r\n<p><strong>Discretionary Access Control:</strong> 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. The TOE 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.</p>\r\n<p>&nbsp;</p>\r\n<p>The TOE can operate in two different modes of operation called &ldquo;CAPP mode&rdquo; and &ldquo;MLS mode&rdquo;.</p>\r\n<p>In CAPP mode the SELinux security module does not enforce a mandatory access control policy and does not recognize sensitivity labels of subjects and objects.&nbsp; In MLS mode the SELinux security module is configured to enforce the mandatory access control policy based on the labels of subjects and objects as specified by functional requirement derived from the sunsetted LSPP and RBAC protection profiles.</p>\r\n<p>&nbsp;</p>\r\n<p><strong>Mandatory Access Control:</strong> Mandatory Access Control (MAC) restricts access to object based on labels assigned to subjects and objects. The TOE implements the Bell-LaPadula access control ruleset which is based on labels with a hierarchical sensitivity label and a set of non-hierarchical categories.&nbsp; MAC is available in MLS mode only.</p>\r\n<p><strong>&nbsp;</strong></p>\r\n<p><strong>Role-based Access Control:</strong> Role-based Access Control (RBAC) restricts access to objects based on roles assigned to subjects. The TOE allows the specification of roles, the assignment of users to roles and the definition of the capability of roles.&nbsp; RBAC is available in MLS mode only.&nbsp; The role-based functionality claims are derived from the now sunsetted LSPP and RBAC protection profiles.</p>\r\n<p>&nbsp;</p>\r\n<p><strong>Object Reuse:</strong> 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.</p>\r\n<p>&nbsp;</p>\r\n<p><strong>Security Management:</strong> The management of the security critical parameters of the TOE is performed by administrative users. A set of commands that require root privileges are used for system management. 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.</p>\r\n<p>&nbsp;</p>\r\n<p><strong>Secure Communication:</strong> The TOE supports the definition of trusted channels using the SSH v2, SSL v3 or TLSv1 protocols. The TOE includes SSH server and client functions. Password based authentication is supported. To use the SSLv3/TLSv1 protocols the TOE provides the Stunnel client and server functions. A restricted number of cipher suites are supported for those protocols in the evaluated configuration and are listed in the Security Target.</p>\r\n<p>&nbsp;</p>\r\n<p><strong>TSF Protection:</strong> While in operation, the kernel software and data are protected by 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/RBAC and process isolation mechanisms. In the evaluated configuration, the reserved user ID &ldquo;root&rdquo; 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/MAC/RBAC permissions. The TOE and the hardware and firmware components are required to be physically protected from unauthorized access. The system kernel mediates all access to the hardware mechanisms themselves, other than program visible CPU instruction functions.</p>\r\n<p>&nbsp;</p>\r\n<p>The cryptography used in this product was tested using a cipher compliance test approach, which used the methodology prescribed by the NIST Cryptographic Algorithm Validation Scheme. Those security functions included as FIPS Approved functions were tested by the cryptographic test laboratory and validated by NIST's Cryptographic Algorithm Validation Program. The accredited laboratory used the CAVS tool version 5.1. A similar test methodology to that used by NIST was developed for the non-FIPS Approved RC4 algorithm using the ARCFOUR definition as a reference implementation, in order to test for successful implementation of the algorithm. The method is described in the laboratory's &ldquo;Developed Methods&rdquo;. The testing for implementation correctness of this algorithm (RC4) was NOT validated by NIST nor any other independent third party.</p>","features":[]}