The TOE supports (sometimes optionally) secure connectivity with several other IT environment devices as described in the table below:
\r\n| \r\n\r\n | \r\n\r\n Required \r\n | \r\n\r\n Usage/Purpose Description for TOE performance \r\n | \r\n
| \r\n Workstation with SSH Client \r\n | \r\n\r\n No \r\n | \r\n\r\n This includes any IT Environment Management workstation with an SSH client installed that is used by the TOE users (including administrators) to remotely connect to the TOE through SSH protected channels. Any SSH client that supports SSHv2 may be used. \r\n | \r\n
| \r\n Audit Server \r\n | \r\n\r\n No \r\n | \r\n\r\n The audit server is used for remote storage of audit records that have been generated by and transmitted from the TOE. \r\n | \r\n
| \r\n Update Server \r\n | \r\n\r\n Yes \r\n | \r\n\r\n Provides the ability to check for updates to the TOE as well as providing signed updates. \r\n | \r\n
The TOE itself does not have physical boundaries; however, the TOE was evaluated on the following hardware:
\r\n| \r\n Vendor \r\n | \r\n\r\n Model \r\n | \r\n\r\n CPU \r\n | \r\n
| \r\n Dell Inc. \r\n | \r\n\r\n PowerEdge R440 \r\n | \r\n\r\n Xeon Silver 42xx \r\n | \r\n
| \r\n Dell Inc. \r\n | \r\n\r\n PowerEdge R540 \r\n | \r\n\r\n Xeon Silver 42xx \r\n | \r\n
| \r\n Dell Inc. \r\n | \r\n\r\n PowerEdge R640 \r\n | \r\n\r\n Xeon Silver 42xx \r\n | \r\n
| \r\n Dell Inc. \r\n | \r\n\r\n PowerEdge R740 \r\n | \r\n\r\n Xeon Silver 42xx \r\n | \r\n
| \r\n Dell Inc. \r\n | \r\n\r\n PowerEdge R740XD \r\n | \r\n\r\n Xeon Silver 42xx \r\n | \r\n
| \r\n Dell Inc. \r\n | \r\n\r\n PowerEdge R840 \r\n | \r\n\r\n Xeon Silver 42xx \r\n | \r\n
| \r\n Dell Inc. \r\n | \r\n\r\n PowerEdge R940 \r\n | \r\n\r\n Xeon Silver 42xx \r\n | \r\n
| \r\n Dell Inc. \r\n | \r\n\r\n PowerEdge R940xa \r\n | \r\n\r\n Xeon Silver 42xx \r\n | \r\n
The Xeon Silver 4200 series processors are 2nd Generation Intel® Xeon® Scalable Processors and implement the Cascade Lake microarchitecture.
\r\nThe TOE was tested on a PowerEdge R740 with a Xeon Silver 4216 CPU.
","evaluation_configuration":"","security_evaluation_summary":"The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) process and scheme. The criteria against which the Red Hat Enterprise Linux was evaluated are described in the Common Criteria for Information Technology Security Evaluation, Version 3.1 rev 5. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 rev 5. Acumen Security determined that the evaluation assurance level (EAL) for the product is EAL 1. The product, when delivered configured as identified in the Red Hat Enterprise Linux 8.2 CC Guidance, satisfies all of the security functional requirements stated in the Red Hat Enterprise Linux 8.2 Security Target. The project underwent CCEVS Validator review. The evaluation was completed in March 2022. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report prepared by CCEVS.
","environmental_strengths":"The TOE provides the security functionality required by [GPOSPP] and [SSHEP].
\r\nSecurity Audit
\r\nThe TOE generates and stores audit events using the Lightweight Audit Framework (LAF). The LAF is designed to be an audit system making Linux compliant with the requirements from Common Criteria by intercepting all system calls and retrieving audit log entries from privileged user space applications. The framework allows configuring the events to be recorded from the set of all events that are possible to be audited. Each audit record contains the date and time of event, type of event, subject identity, user identity, and result (success/fail) of the action if applicable.
\r\nCryptographic Support
\r\nThe TOE provides a broad range of cryptographic support; providing SSHv2 and TLSv1.2 protocol implementations in addition to individual cryptographic algorithms.
\r\nThe cryptographic services provided by the TOE are described below:
\r\n| \r\n Cryptographic Protocol \r\n | \r\n\r\n Use within the TOE \r\n | \r\n
| \r\n SSH Client \r\n | \r\n\r\n The TOE allows administrators and users to connect to remote SSH servers. \r\n | \r\n
| \r\n SSH Server \r\n | \r\n\r\n The TOE allows remote administrators to connect using SSH. \r\n | \r\n
| \r\n TLS Client \r\n | \r\n\r\n The TOE connects to remote trusted IT entities using TLS. \r\n | \r\n
Table 1 TOE Cryptographic Protocols
\r\nThe TOE includes the OpenSSL cryptographic library. Each cryptographic algorithm has been validated for conformance to the requirements specified in their respective standards as identified below:
\r\n| \r\n Algorithm \r\n | \r\n\r\n Related SFRs \r\n | \r\n\r\n TOE Use \r\n | \r\n\r\n CAVP Certificate # \r\n | \r\n
| \r\n OpenSSL 1.1.1c with algorithm version rhel8.20210325cc \r\n | \r\n|||
| \r\n AES \r\n | \r\n\r\n FCS_COP.1(1) \r\nFCS_COP.1(1)/SSH \r\nFCS_SSHC_EXT.1 \r\nFCS_SSHS_EXT.1 \r\nFCS_TLSC_EXT.1 \r\nFCS_STO_EXT.1 \r\n | \r\n\r\n SSH AES CBC and CTR modes with 128 and 256-bit keys \r\nTLS AES CBC and GCM modes with 128 and 256-bit keys \r\nFile Encryption using AES CBC with 128 and 256-bit keys \r\n | \r\n\r\n\r\n | \r\n
| \r\n Diffie-Hellman \r\n | \r\n\r\n FCS_CKM.2 \r\nFCS_TLSC_EXT.1 \r\n | \r\n\r\n TLS Diffie-Hellman Group 14 Key Establishment \r\n | \r\n\r\n N/A \r\n | \r\n
| \r\n DRBG \r\n | \r\n\r\n FCS_RBG_EXT.1 \r\n | \r\n\r\n CTR_DRBG (AES-256) \r\n | \r\n\r\n\r\n | \r\n
| \r\n ECDSA \r\n | \r\n\r\n FCS_CKM.1 \r\nFCS_COP.1(3) \r\nFCS_SSHC_EXT.1 \r\nFCS_SSHS_EXT.1 \r\nFCS_TLSC_EXT.1 \r\nFCS_TLSC_EXT.2 \r\n | \r\n\r\n SSH ECDSA P-256 and P-384 Host Key and User Key Generation \r\nSSH EC Diffie-Hellman P-256, P-384, and P-521 Key Generation \r\nSSH ECDSA P-256 and P-384 Host and User Signature Generation and Verification \r\nTLS ECDSA P-256, P-384, and P-521 Client Key Generation \r\nTLS EC Diffie-Hellman P-256, P-384, and P-521 Key Generation \r\nTLS ECDSA P-256, P-384, and P-521 Signature Generation and Verification \r\n | \r\n\r\n\r\n | \r\n
| \r\n HMAC \r\n | \r\n\r\n FCS_COP.1(4) \r\nFCS_SSHC_EXT.1 \r\nFCS_SSHS_EXT.1 \r\nFCS_TLSC_EXT.1 \r\n | \r\n\r\n SSH HMAC-SHA-256 and HMAC-SHA-512 \r\nTLS HMAC-SHA-256, and HMAC-SHA-384 \r\nTLS HMAC-SHA-256 and HMAC-SHA-384 Key Derivation \r\n | \r\n\r\n\r\n | \r\n
| \r\n KAS \r\n | \r\n\r\n FCS_CKM.2 \r\nFCS_SSHC_EXT.1 \r\nFCS_SSHS_EXT.1 \r\nFCS_TLSC_EXT.2 \r\n | \r\n\r\n SSH EC Diffie-Hellman P-256, P-384, and P-521 Key Establishment \r\nTLS EC Diffie-Hellman P-256, P-384, and P-521 Key Establishment \r\n | \r\n\r\n\r\n | \r\n
| \r\n RSA \r\n | \r\n\r\n FCS_CKM.1 \r\nFCS_CKM.2 \r\nFCS_COP.1(3) \r\nFCS_SSHC_EXT.1 \r\nFCS_SSHS_EXT.1 \r\nFCS_TLSC_EXT.1 \r\nFPT_TST_EXT.1 \r\nFPT_TUD_EXT.1 \r\nFPT_TUD_EXT.2 \r\n | \r\n\r\n SSH RSA 2048-bit, 3072-bit, and 4096-bit Host Key and User Key Generation \r\nSSH RSA 2048-bit, 3072-bit, and 4096-bit Host and User Signature Generation and Verification \r\nTLS RSA 2048-bit, 3072-bit, and 4096-bit Client Key Generation \r\nTLS RSA 2048-bit, 3072-bit, and 4096-bit Key Establishment (CAVP certificate is N/A) \r\nTLS RSA 2048-bit, 3072-bit, and 4096-bit Signature Generation and Verification \r\nSelf-Test RSA 2048 Signature Verification \r\nTrusted Update RSA 4096 Signature Verification \r\n | \r\n\r\n\r\n | \r\n
| \r\n SHS \r\n | \r\n\r\n FCS_COP.1(2) \r\nFCS_SSHC_EXT.1 \r\nFCS_SSHS_EXT.1 \r\n | \r\n\r\n SHA-256, SHA-384, and SHA-512 Key Derivation \r\nSHA-256, SHA-384, and SHA-512 for Digital Signatures and HMACs \r\n | \r\n\r\n\r\n | \r\n
Table 2 CAVP Algorithm Testing References
\r\nThe OpenSSL library provides the TLS Client function. The OpenSSL library also provides the cryptographic algorithms for the SSH Client, SSH Server, trusted update, and secure boot security functions.
\r\nUser Data Protection
\r\nDiscretionary Access Control (DAC) allows the TOE to assign owners to file system objects and Inter-Process Communication (IPC) objects. The owners are allowed to modify Unix-type permission bits for these objects to permit or deny access for other users or groups. The DAC mechanism also ensures that untrusted users cannot tamper with the TOE mechanisms.
\r\nThe TOE also implements POSIX Access Control Lists (ACLs) that allow the specification of the access to individual file system objects down to the granularity of a single user.
\r\nIdentification and Authentication
\r\nUser identification and authentication in the TOE includes all forms of interactive login (e.g. using the SSH protocol or log in at the local console) as well as identity changes through the su or sudo command. These all rely on explicit authentication information provided interactively by a user.
\r\nThe authentication security function allows password-based authentication. For SSH access, public-key-based authentication is also supported.
\r\nPassword quality enforcement mechanisms are offered by the TOE which are enforced at the time when the password is changed.
\r\nSecurity Management
\r\nThe security management facilities provided by the TOE are usable by authorized users and/or authorized administrators to modify the configuration of TSF.
\r\nProtection of the TSF
\r\nThe TOE implements self-protection mechanisms that protect the security mechanisms of the TOE as well as software executed by the TOE. The following self-protection mechanisms are implemented and enforced:
\r\nTOE Access
\r\nThe TOE displays informative banners before users are allowed to establish a session.
\r\nTrusted Path/Channels
\r\nThe TOE supports TLSv1.2 and SSHv2 to secure remote communications. Both protocols may be used for communications with remote IT entities. Remote administration is only supported using SSHv2.
","features":[]}