Oracle Linux 9.3 Security Target February 14, 2025 V1.5 Prepared By: Primasec Limited 6 Rue d’Alsace 11120 St Marcel-sur-Aude France Prepared for: Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Copyright © 2025 by Oracle Corporation Page 2 of 68 Trademarks Oracle Linux and the Oracle logo are trademarks or registered trademarks of Oracle Corporation 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. Intel, Xeon, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. AMD and EPYC are trademarks of AMD Corporation in the United States, other countries, or both. Ampere and Altra are trademarks of Ampere Corporation in the United States, other countries, or both. Legal Notice This document is provided AS IS with no express or implied warranties. Use the information in this document at your own risk. 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. Page 3 of 68 Table Of Contents 1 Security Target Introduction.................................................................................................................7 1.1 Security Target and TOE Reference .................................................................................................7 1.2 TOE Overview...................................................................................................................................8 1.2.1 TOE Product Type......................................................................................................................8 1.3 TOE Architecture..............................................................................................................................8 1.3.1 Physical Boundaries...................................................................................................................8 1.3.2 Logical Scope of the TOE ...........................................................................................................9 1.4 Excluded Functionality...................................................................................................................15 1.5 TOE Documentation.......................................................................................................................16 1.6 Other References...........................................................................................................................16 2 Conformance Claims...........................................................................................................................17 2.1 CC Conformance ............................................................................................................................17 2.2 Protection Profile Conformance ....................................................................................................17 2.3 Conformance Rationale .................................................................................................................17 2.3.1 Technical Decisions .................................................................................................................17 3 Security Problem Definition................................................................................................................20 3.1 Threats ...........................................................................................................................................20 3.2 Assumptions...................................................................................................................................20 3.3 Organizational Security Policies.....................................................................................................21 4 Security Objectives..............................................................................................................................22 4.1 Security Objectives for the TOE .....................................................................................................22 4.2 Security Objectives for the Operational Environment...................................................................23 4.3 Rationale for Security Objectives...................................................................................................23 5 Extended Security Functional Components........................................................................................25 5.1 List of Extended Security Functional Components ........................................................................25 5.2 Extended Security Functional Components Rationale...................................................................25 6 Security Requirements........................................................................................................................26 6.1 List of TOE Security Functional Requirements...............................................................................26 6.2 Conventions ...................................................................................................................................27 Page 4 of 68 6.3 Security Functional requirements..................................................................................................27 6.3.1 Security Audit (FAU) ................................................................................................................27 6.3.2 Cryptographic Support (FCS)...................................................................................................28 6.3.3 User Data Protection (FDP) .....................................................................................................33 6.3.4 Identification and Authentication (FIA)...................................................................................33 6.3.5 Security Management (FMT)...................................................................................................35 6.3.6 Protection of the TSF (FPT)......................................................................................................36 6.3.7 Trusted path/channels (FTP)...................................................................................................37 6.4 TOE SFR Dependencies Rationale for SFRs ....................................................................................38 6.5 Security Assurance Requirements .................................................................................................38 6.6 Rationale for Security Assurance Requirements ...........................................................................38 6.7 Assurance Measures......................................................................................................................38 7 TOE Summary Specification................................................................................................................41 8 Annex A: References...........................................................................................................................58 9 Annex B - Extended Security Functional Components........................................................................59 9.1 Cryptographic Support (FCS)..........................................................................................................59 9.1.1 FCS_CKM_EXT.4 Cryptographic Key Destruction ....................................................................59 9.1.2 FCS_RBG_EXT.1 Random Bit Generation ................................................................................60 9.1.3 FCS_STO_EXT.1 Storage of Sensitive Data .............................................................................60 9.1.4 FCS_TLSC_EXT.1 TLS Client Protocol .......................................................................................60 9.1.5 FCS_TLSC_EXT.5 TLS Client Support for Supported Groups Extension ...................................61 9.1.6 FCS_SSH_EXT.1 SSH Protocol ..................................................................................................61 9.1.7 FCS_SSHC_EXT.1 SSH Protocol - Client....................................................................................62 9.1.8 FCS_SSHS_EXT.1 SSH Protocol - Server...................................................................................62 9.2 User Data Protection (FDP)............................................................................................................62 9.2.1 FDP_IFC_EXT.1 Information flow control................................................................................62 9.2.2 FDP_ACF_EXT.1 Access Controls for Protecting User Data.....................................................63 9.3 Identification and Authentication (FIA) .........................................................................................63 9.3.1 FIA_X509_EXT.1 X.509 Certificate Validation..........................................................................63 9.3.2 FIA_X509_EXT.2 X.509 Certificate Authentication..................................................................64 9.4 Security Management (FMT) .........................................................................................................64 9.4.1 FMT_MOF_EXT.1 Management of security functions behavior.............................................64 9.4.2 FMT_SMF_EXT.1 Specification of Management Functions.....................................................64 9.5 Protection of the TSF (FPT) ............................................................................................................65 9.5.1 FPT_ACF_EXT.1 Access controls..............................................................................................65 Page 5 of 68 9.5.2 FPT_ASLR_EXT.1 Address Space Layout Randomization.........................................................65 9.5.3 FPT_SBOP_EXT.1 Stack Buffer Overflow Protection ...............................................................65 9.6 FPT_TST_EXT.1 Boot Integrity........................................................................................................66 9.6.1 FPT_TUD_EXT.1 Trusted Update.............................................................................................66 9.6.2 FPT_TUD_EXT.2 Trusted Update for Application Software.....................................................66 9.7 Trusted Path/Channels (FTP) .........................................................................................................66 9.7.1 FTP_ITC_EXT.1 Trusted channel communication....................................................................66 10 Annex C - Extended Security Assurance Components....................................................................68 10.1 Life Cycle (ALC)...............................................................................................................................68 10.1.1 ALC_TSU_EXT.1 Timely Security Updates ...............................................................................68 Page 6 of 68 Revision History Version Date Description 1.0 10/21/2024 Certification version 1.1 11/16/2024 Algorithm certificates updated 1.2 11/18/2024 Guidance document version updated 1.3 02/02/2025 Updated following review and added technical decision 1.4 02/04/2025 Updated following review 1.5 02/14/2025 Updated following review Page 7 of 68 1 Security Target Introduction 1.1 Security Target and TOE Reference This section provides information needed to identify and control this ST and its TOE. Category Identifier ST Title Oracle Linux 9.3 Security Target ST Version 1.5 ST Date February 14, 2025 ST Author Primasec Limited TOE Identifier Oracle Linux 9.3 with the following package updates: Note: Dependencies for additional packages will be installed automatically. c-ares.x86_64 1.19.1-2.el9_4 curl.x86_64 7.76.1-29.el9_4.1 expat.x86_64 2.5.0-2.el9_4.1 file.x86_64 5.39-16.el9 glibc.x86_64 2.34-100.0.1.el9_4.3 glib2.x86_64 2.68.4-14.el9_4.1 gnutls.x86_64 3.8.3-4.el9_4 grub2-common.noarch 1:2.06-82.0.1.el9_4 iwl100-firmware.noarch 999:39.31.5.1-999.34.el9 * iwl1000-firmware.noarch 999:39.31.5.1-999.34.el9 * iwl105-firmware.noarch 999:18.168.6.1-999.34.el9 * iwl2000-firmware.noarch 999:18.168.6.1-999.34.el9 * iwl2030-firmware.noarch 999:18.168.6.1-999.34.el9 * iwl3160-firmware.noarch 999:25.30.13.0-999.34.el9 * iwl5000-firmware.noarch 999:8.83.5.1_1-999.34.el9 * iwl5150-firmware.noarch 999:8.24.2.2-999.34.el9 * iwl6000g2a-firmware.noarch 999:18.168.6.1-999.34.el9 * iwl6050-firmware.noarch 999:41.28.5.1-999.34.el9 * iwl7260-firmware.noarch 999:25.30.13.0-999.34.el9 * iwlax2xx-firmware.noarch 999:20240715-999.34.el9 * kernel-uek.x86_64 5.15.0-300.163.18.el9uek kernel.x86_64 5.14.0-427.37.1.el9_4 kernel-tools.x86_64 5.14.0-427.37.1.el9_4 kernel-tools-libs.x86_64 5.14.0-427.37.1.el9_4 krb5-libs.x86_64 1.21.1-2.0.1.el9_4 less.x86_64 590-4.el9_4 libnghttp2.x86_64 1.43.0-5.el9_4.3 libndp.x86_64 1.8-6.el9_4 libssh.x86_64 0.10.4-13.el9 libxml2.x86_64 2.9.13-6.el9_4 linux-firmware.noarch 999:20240715-999.34.git4c8fb21e.el9 linux-firmware-core.noarch 999:20240715-999.34.git4c8fb21e.el9 linux-firmware-whence.noarch 999:20240715-999.34.git4c8fb21e.el9 microcode_ctl.noarch 4:20231114-0.1.el9 * openssh.x86_64 8.7p1-38.0.2.el9_4.4 openssl.x86_64 1:3.0.7-28.0.1.el9_4 openssl-fips-provider.x86_64 3.0.7-2.0.1.el9 Page 8 of 68 Category Identifier pam.x86_64 1.5.1-19.0.2.el9 python3.x86_64 3.9.18-3.el9_4.5 python3-cryptography.x86_64 36.0.1-4.0.1.el9 python3-setuptools-wheel.noarch 53.0.0-12.el9_4.1 rpm.x86_64 4.16.1.3-29.el9 sssd-common.x86_64 2.9.4-6.0.1.el9_4.1 squashfs-tools.x86_64 4.4-10.git1.el9 sqlite-libs.x86_64 3.34.1-7.el9_3 sudo.x86_64 1.9.5p2-10.el9_3 systemd.x86_64 252-32.0.2.el9_4.7 Packages marked with * are not applicable to the ARM platform TOE Software Version 9.3 TOE Kernels UEK Kernel, RHCK Kernel TOE Developer Oracle Corporation Key Words Operating System, Oracle, Linux 9.3 Table 1 - TOE/ST Identification 1.2 TOE Overview Oracle Linux 9.3 (herein referred to as the TOE) is a Linux-based operating system. Oracle Linux is a general purpose, multi-user, multi-tasking Linux based operating system. It provides a platform for a variety of applications. 1.2.1 TOE Product Type The TOE type is a Linux-based general-purpose operating system which supports secure remote login and other secure network services over an untrusted network using Secure Shell (SSH). It satisfies all the criterion to meet the Protection Profile for General Purpose Operating Systems Version 4.3 [GPOSPP] and the Functional Packages for SSH Version 1.0 [PKG_SSH] and TLS version 1.1 [PKG_TLS]. 1.3 TOE Architecture 1.3.1 Physical Boundaries The evaluated configuration includes the general-purpose hardware with the following processors: • Oracle Linux 9.3 on KVM (Oracle Linux 8) onAMD EPYC 7J13 (UEK and RHCK Kernel) • Oracle Linux 9.3 on KVM (Oracle Linux 8) on Intel Icelake Xeon Platinum 8358 (UEK and RHCK Kernel) • Oracle Linux 9.3 on KVM (Oracle Linux 8) on Ampere Altra Q80-30 (UEK Kernel) The Target of Evaluation is based on the following system software: • Oracle Linux 9.3 The TOE and its documentation are supplied on ISO images distributed via the Oracle Linux web site. In addition to the installation media, the following documentation is provided: Page 9 of 68 • Evaluated Configuration Guide published by Oracle at the end of the evaluation • Manual pages for all applications, configuration files and system calls The components in Table 2 must be present in the operational environment to support operation of the TOE in its evaluated configuration. Component Usage Computing platform The hardware platforms for the TOE software included in the evaluation are listed above. Update server Provides signed updates to the TOE software. Remote servers Provide support for TLS, Certificate Revocation Lists and SSH. Table 2 – TOE Environment Components 1.3.2 Logical Scope of the TOE The TOE implements the following security functional requirements from [GPOSPP], [PKG_SSH] and [PKG_TLS] as listed below: 1.3.2.1 Audit Data Generation (FAU) The TOE generates audit events for all start-up and shut-down functions, and all auditable events as specified in Section 6.2.1. The TOE leverages the Lightweight Audit Framework (LAF) audit system. Audit events are generated for the following audit functions: • Start-up and shut-down of the audit functions; • Authentication events (Success/Failure); • Use of privileged/special rights events (Successful and unsuccessful security, audit, and configuration changes) • Privilege or role escalation events (Success/Failure) Each audit record contains the date and time of the event, type of event, subject identity (if applicable), and outcome (success or failure) of the event. 1.3.2.2 Cryptographic Support (FCS) The TOE provides cryptographic support for the services described in Table 3. The TOE leverages the Oracle Linux 9.3 OpenSSL 3.0 (64 bit) cryptographic library for SSH and TLS related cryptographic operations. The related CAVP validation details are provided in Table 4. The TOE provides an interface for the protection of stored credentials, and uses AES-CBC, AES-CTR and GCM with key size of 256 bits along with SHA-256, SHA-384, and SHA-512. The related CAVP validation details are provided in Table 4. The cryptographic services provided by the TOE are described below. Cryptographic Method Usage FCS_CKM.1 Cryptographic Key Generation (Refined) • RSA schemes using cryptographic key sizes of 3072-bit or greater that meet the following: FIPS Page 10 of 68 1 TD0696 has been applied. Cryptographic Method Usage PUB 186-5, "Digital Signature Standard (DSS)", Appendix B.3. • RSA Key sizes supported are 3072 bits and 4096 bits. • ECC schemes using "NIST curves" P-384 and P-521 that meet the following: FIPS PUB 186-5, "Digital Signature Standard (DSS)", Appendix B.4. • Elliptic NIST curves supported are: P-384 and P- 521. • FFC scheme using safe primes that meet the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes”. FCS_CKM.2 Cryptographic Key Establishment (Refined) • Elliptic curve-based key establishment schemes that meets the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair- Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”. • Finite field-based key establishment conforming to NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography. FCS_CKM_EXT.4 Cryptographic Key Destruction • For volatile memory, the destruction shall be executed by removal of power to the memory. • For non-volatile memory, destruction consists of the invocation of an interface provided by the underlying platform that instructs the underlying platform to destroy the abstraction that represents the key. FCS_COP.1/ENCRYPT Cryptographic Operation - Encryption/Decryption (Refined) • AES-CBC (as defined in NIST SP 800-38A) • AES-CTR (as defined in NIST SP 800-38A) • AES-GCMP (as defined in NIST SP 800-38D and IEEE 802.11ac-2013 ) • AES key size supported is 256 bits FCS_COP.1/HASH Cryptographic Operation - Hashing (Refined)1 • Cryptographic hashing services conforming to FIPS Pub 180-4. • Hashing algorithms supported are: SHA-256, SHA- 384 and SHA-512. Page 11 of 68 Cryptographic Method Usage • Message digest sizes supported are 256 bits, 384 bits and 512 bits. FCS_COP.1/SIGN Cryptographic Operation - Signing (Refined) • RSA digital signature algorithm conforming to FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 4. • ECDSA schemes using "NIST curves" P-384 and [P- 521] that meet the following: FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 5 • RSA key sizes supported are: 3072 and 4096 bits. FCS_COP.1/KEYHMAC Cryptographic Operation - Keyed-Hash Message Authentication (Refined) • Keyed-hash message authentication services in conforming to FIPS Pub 198-1 The Keyed-Hash Message Authentication Code and FIPS Pub 180-4 Secure Hash Standard. • Keyed hash algorithm authentication services in accordance with the following specified cryptographic algorithms: SHA-256, SHA-384 and SHA-512. • Key sizes supported are: 112 bits. • Message digest sizes supported are: 256 bits, 384 bits and 512 bits. FCS_RBG_EXT.1 Random Bit Generation • Random number generation conforming to NIST Special Publication 800-90A. • The TOE leverages CTR_DRBG (AES). • The deterministic RBG used by the OS is seeded by an entropy source that accumulates entropy from a platform-based noise source with a minimum of 256 bits of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate. FCS_STO_EXT.1 Storage of Sensitive Data • The OS implements functionality to encrypt sensitive data stored in non-volatile storage and provides interfaces to applications to invoke the functionality. FCS_SSH_EXT.1 SSH Protocol • SSH protocol that complies with RFCs 4251, 4252, 4253, 4254 and 6668 as a client and server. • The TOE supports password-based authentication (RFC 4252) and public key authentication (RFC 4252). • The following public key algorithm is supported: rsa-sha2-256 (RFC 8332), rsa-sha2-512 (RFC 8332), Page 12 of 68 Cryptographic Method Usage ecdsa-sha2-nistp384 (RFC 5656), and ecdsa-sha2- nistp521 (RFC 5656). • The SSH client shall ensure that, as described in RFC 4253, packets greater than 262144 bytes in an SSH transport connection are dropped. • The TOE supports the following encryption algorithm: aes256-ctr (RFC 4344). • The TOE supports the following data integrity MAC algorithms: hmac-sha2-256 (RFC 6668) and hmac- sha2-512 (RFC 6668). • The TOE supports the following key exchange algorithm: ecdh-sha2-nistp384 (RFC 5656), and ecdh-sha2-nistp521 (RFC 5656). • The TOE uses SSH KDF as defined in • RFC 4253 (Section 7.2), and RFC 5656 (Section 4), • to derive the following cryptographic keys from a shared secret. • The TOE supports a rekey of the session keys occurs when any of the following thresholds are met: one hour of connection time, no more than one gigabyte of transmitted data, or no more than one gigabyte of received data. FCS_SSHC_EXT.1 SSH Protocol - Client FCS_SSHS_EXT.1 SSH Protocol - Server • The TOE shall authenticate its peer (SSH server) using a local database by associating each host name with a public key corresponding to the following: rsa-sha2-256 (RFC 8332), rsa-sha2-512 (RFC 8332), ecdsa-sha2-nistp384 (RFC 5656), and ecdsa-sha2-nistp521 (RFC 5656) as described in RFC 4251 section 4.1. • The TSF shall authenticate itself to its peer (SSH Client) using: rsa-sha2-256 (RFC 8332), rsa-sha2- 512 (RFC 8332), ecdsa-sha2-nistp384 (RFC 5656), and ecdsa-sha2-nistp521 (RFC 5656). FCS_TLSC_EXT.1 TLS Client Protocol • The TOE supports TLS v1.2 protocol • The TOE supports the following cipher suites in the evaluated configuration: • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 Page 13 of 68 Table 3 - TOE Cryptographic Protocols Each of these cryptographic algorithms have been validated for conformance to the requirements specified in their respective standards, as identified below. Algorithms Standards Implementation CAVP Certificates # Processors AES • AES-CBC (as defined in NIST SP 800-38A) • AES-CTR (as defined in NIST SP 800-38A) • AES_GCMP (as defined in NIST SP 800- 38D) OpenSSL (64 bit) Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 • Ampere Altra Q80-30 RSA • FIPS PUB 186-5 Digital Signature Standard (DSS), Appendix B.3. • OpenSSL (64 bit) Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 • Ampere Altra Q80-30 ECDSA • FIPS PUB 186-5, "Digital Signature Standard (DSS)", Appendix B.4 • OpenSSL (64 bit) Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 • Ampere Altra Q80-30 ECDH • NIST Special Publication 800-56A Revision 3 • OpenSSL (64 bit) Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 • Ampere Altra Q80-30 DH • Complies with RFC 3526 • OpenSSL (64 bit) Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 • Ampere Altra Q80-30 KAS/CVL ECC • NIST Special Publication 800-56A • OpenSSL (64 bit) Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 Cryptographic Method Usage FCS_TLSC_EXT.5 TLS Client Protocol • The OS shall present the Supported Elliptic Curves Extension in the Client Hello with the following NIST curves: secp384r1, and secp521r1. Page 14 of 68 Algorithms Standards Implementation CAVP Certificates # Processors • Ampere Altra Q80-30 KAS/CVL FCC • NIST Special Publication 800-56A • OpenSSL (64 bit) Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 • Ampere Altra Q80-30 HMAC • Keyed-hash message authentication services in conforming to FIPS Pub 198-1 The Keyed-Hash Message Authentication Code and FIPS Pub 180-4 Secure Hash Standard OpenSSL (64 bit) Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 • Ampere Altra Q80-30 SHS • NIST FIPS Pub 180-4. OpenSSL (64 bit) Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 • Ampere Altra Q80-30 DRBG • Random number generation conforming to NIST Special Publication 800-90A. • OpenSSL (64 bit) Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 • Ampere Altra Q80-30 CVL SSH v2 • KDF 800-135 • OpenSSL (64 bit) • Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 • Ampere Altra Q80-30 CVL TLS v1.2 • KDF 800-135 • OpenSSL (64 bit) Version 3.0 A6141 • AMD EPYC 7J13 • Intel Xeon Platinum 8358 • Ampere Altra Q80-30 Table 4 - CAVP Algorithm Testing References 1.3.2.3 User Data Protection (FDP) The TOE implements access controls which prevents unprivileged users from accessing files and directories owned by other users. The TOE provides an interface which allows VPN client to protect all IP traffic using IPSEC protocol. Page 15 of 68 1.3.2.4 Identification and Authentication (FIA) All users must be authenticated to the TOE prior to carrying out any management actions. The TOE supports password-based authentication and public key based authentication. The OS disables user accounts after a configurable number of unsuccessful authentication attempts. 1.3.2.5 Security Management (FMT) The TOE is capable of performing management functions. The administrator has full access to carry-out all management functions and the user has limited privilege. 1.3.2.6 Protection of the TSF (FPT) The TOE implements the following protection of TSF data: • Access Controls • Address Space Layout Randomization • Stack buffer overflow protection using stack canaries. • Verification of integrity of the bootchain • Trusted software updates 1.3.2.7 Trusted Path/Channels The TOE supports TLS v1.2 and SSH v2 for trusted channel implementation. The TOE supports remote CLI using SSH v2 for secure remote administration. 1.4 Excluded Functionality The following interfaces are not included as part of the evaluated configuration. All interfaces below are disabled in the evaluated configuration: Functions Exclusion discussion GUI A graphical user interface for system administration or any other operation is not included in the evaluated configuration. LSM Support The mandatory access control functionality offered by the Linux Security Module (LSM) framework found in the Linux kernel is not assessed by the evaluation and disabled in the evaluated configuration. All LSM modules such as SELinux, AppArmor, SMACK and others are not assessed as part of the evaluation. The evaluated configuration enables aspects of the LSM though. GSS-API Security Mechanisms The GSS-API is used to secure the connection between different audit daemons. The security mechanisms used by the GSS-API, however, are disabled in the evaluated configuration. Table 5 - Excluded Functionality Page 16 of 68 1.5 TOE Documentation The following documents are available in PDF formats. Documentation Version Date Oracle Linux 9.3 Common Criteria Guidance Document 1.4 February 2025 Oracle Linux 9 Installing Oracle Linux F51031-13 October 2024 Oracle Linux 9 Enhancing System Security F84093-03 August 2024 Oracle Linux 9 Connecting to Remote Systems with OpenSSH F22963-13 April 2024 Oracle Linux 9 Setting Up System Users and Authentication F56873-06 January 2024 Table 6 - TOE Documentation 1.6 Other References • Protection Profile for General Purpose Operating Systems, Version 4.3 [GPOSPP] • Functional Package for Transport Layer Security (TLS), version 1.1 [PKG_TLS] • Functional Package for Secure Shell (SSH), Version 1.0 [PKG_SSH] Page 17 of 68 2 Conformance Claims 2.1 CC Conformance This TOE is conformant to: • Common Criteria for Information Technology Security Evaluations Part 1, Version 3.1, Revision 5, April 2017 • Common Criteria for Information Technology Security Evaluations Part 2, Version 3.1, Revision 5, April 2017: Part 2 extended • Common Criteria for Information Technology Security Evaluations Part 3, Version 3.1, Revision 5, April 2017: Part 3 extended 2.2 Protection Profile Conformance This TOE is conformant to: • Protection Profile for General Purpose Operating Systems, Version 4.3 [GPOSPP] • Functional Package for Secure Shell (SSH), Version 1.0 [PKG_SSH] • Functional Package for Transport Layer Security (TLS), Version 1.1 [PKG_TLS] • Assurance Package for Flaw Remediation, Version 1.0 2.3 Conformance Rationale This Security Target provides exact conformance to [GPOSPP], [PKG_SSH} and [PKG_TLS]. The security problem definition, security objectives and security requirements in this Security Target are all taken from the Protection Profile performing only operations defined there. 2.3.1 Technical Decisions All NIAP Technical Decisions (TDs) issued to date that are applicable to [GPOSPP], [PKG_SSH] and [PKG_TLS] have been addressed. The following tables identify all applicable TDs: Identifier Applicable Exclusion Rationale (if applicable) TD0873 Updating FIPS 186-4 to 186-5 in PP_OS_V4.3 Yes TD0844 Addition of Assurance package for Flaw Remediation V1.0 Conformance Claim Yes TD0839 Clarification for Local Administration in FTP_TRP 1.3 Yes TD0821 Corrections to ECD for PP_OS_V4.3 Yes TD0812 Updated CC Conformance Claims in PP_OS_V4.3 Yes Page 18 of 68 Identifier Applicable Exclusion Rationale (if applicable) TD0789 – Correction to TLS selection in FIA_X509_EXT.2. Yes TD0773 – Updates to FIA_X509_EXT.1 for Exception Processing and Test Conditions Yes TD0713 – Functional Package SFR mappings to objectives Yes TD0712 – Support for Bluetooth Standard 5. No Bluetooth not supported TD0701 – Incomplete selection reference in FCS_CKM_EXT.4 TSS activities Yes TD0696 – Removal of 160 bit selection from FCS_COP.1/HASH & FCS_COP.1/KEYHMAC Yes TD0693 – Typos in OSPP 4. Yes TD0691 – OSPP 4.3 Conditional authentication testing Yes TD0675 – Make FPT_W^X_EXT.1 Optional Yes Table 7 - PP_OS_V4.3 Technical Decisions Identifier Applicable Exclusion Rationale (if applicable) TD0777 – Clarification to Selections for Auditable Events for FCS_SSH_EXT.1 Yes TD0732 – FCS_SSHS_EXT.1.3 Test 2 Update Yes TD0695: Choice of 128 or 256 bit size in AES- CTR in SSH Functional Package Yes TD0682: Addressing Ambiguity in GCS_SSHS_EXT.1 Tests Yes Table 8 - PKG_SSH_V1.0 Technical Decisions Page 19 of 68 Identifier Applicable Exclusion Rationale (if applicable) 0779 – Updated Session resumption support in TLS package v1.1 No FCS_TLSS_EXT not claimed 0770 – TLSS.2 connection with no client cert No FCS_TLSS_EXT not claimed 0739 – PKG_TLS_V1.1 has 2 different publication dates No FCS_TLSS_EXT not claimed 0726 – Corrections to (D)TLSS SFRs in TLS 1.1 FP No FCS_TLSS_EXT not claimed 0513 – CA Certificate loading Yes 0499 – Testing with pinned certificates Yes 0469 – Modification of test activity for FCS_TLSS_EXT.1.1 test 4.1 No FCS_TLSS_EXT not claimed 0442 – Updated TLS Ciphersuites for TLS Package Yes Table 9 - PKG_TLS_V1.1 Technical Decisions Page 20 of 68 3 Security Problem Definition The security problem definition has been taken from [GPOSPP] and is reproduced here for the convenience of the reader. The security problem is described in terms of the threats that the TOE is expected to address, assumptions about the operational environment, and any organizational security policies that the TOE is expected to enforce. 3.1 Threats The following threats are drawn directly from the [GPOSPP]. ID Threat T.NETWORK_ATTACK An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may engage in communications with applications and services running on or part of the OS with the intent of compromise. Engagement may consist of altering existing legitimate communications. T.NETWORK_EAVESDROP An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between applications and services that are running on or part of the OS. T.LOCAL_ATTACK An attacker may compromise applications running on the OS. The compromised application may provide maliciously formatted input to the OS through a variety of channels including unprivileged system calls and messaging via the file system. T.LIMITED_PHYSICAL_ACCESS An attacker may attempt to access data on the OS while having a limited amount of time with the physical device. Table 10 - Threats 3.2 Assumptions The following assumptions are drawn directly from the [GPOSPP]. ID Assumption A.PLATFORM The OS relies upon a trustworthy computing platform for its execution. This underlying platform is out of scope of this PP. A.PROPER_USER The user of the OS is not willfully negligent or hostile, and uses the software in compliance with the applied enterprise security policy. At the same time, malicious software could act as the user, so requirements which confine malicious subjects are still in scope. Page 21 of 68 A.PROPER_ADMIN The administrator of the OS is not careless, willfully negligent or hostile, and administers the OS within compliance of the applied enterprise security policy. Table 11 - Assumptions 3.3 Organizational Security Policies The [GPOSPP], [PKG_SSH] and [PKG_TLS] do not define any OSPs. Page 22 of 68 4 Security Objectives The security objectives for the TOE and for the operational environment are taken from [GPOSPP], and are reproduced here for the convenience of the reader. 4.1 Security Objectives for the TOE The table below shows the security objectives for the TOE. ID Objective for the Operation Environment O.ACCOUNTABILITY Conformant OSes ensure that information exists that allows administrators to discover unintentional issues with the configuration and operation of the operating system and discover its cause. Gathering event information and immediately transmitting it to another system can also enable incident response in the event of system compromise. O.INTEGRITY Conformant OSes ensure the integrity of their update packages. OSes are seldom if ever shipped without errors, and the ability to deploy patches and updates with integrity is critical to enterprise network security. Conformant OSes provide execution environment-based mitigations that increase the cost to attackers by adding complexity to the task of compromising systems. O.MANAGEMENT To facilitate management by users and the enterprise, conformant OSes provide consistent and supported interfaces for their security-relevant configuration and maintenance. This includes the deployment of applications and application updates through the use of platform- supported deployment mechanisms and formats, as well as providing mechanisms for configuration and application execution control. O.PROTECTED_STORAGE To address the issue of loss of confidentiality of credentials in the event of loss of physical control of the storage medium, conformant OSes provide data-at-rest protection for credentials. Conformant OSes also provide access controls which allow users to keep their files private from other users of the same system. O.PROTECTED_COMMS To address both passive (eavesdropping) and active (packet modification) network attack threats, conformant OSes provide mechanisms to create trusted channels for CSP and sensitive data. Both CSP and sensitive data should not be exposed outside of the platform. Table 12 - Security Objectives for the TOE Page 23 of 68 4.2 Security Objectives for the Operational Environment The following security objectives for the operational environment assist the TOE in correctly providing its security functionality. These track with the assumptions about the environment. ID Objective for the Operation Environment OE.PLATFORM The OS relies on being installed on trusted hardware. OE.PROPER_USER The user of the OS is not willfully negligent or hostile, and uses the software within compliance of the applied enterprise security policy. Standard user accounts are provisioned in accordance with the least privilege model. Users requiring higher levels of access should have a separate account dedicated for that use. OE.PROPER_ADMIN The administrator of the OS is not careless, willfully negligent or hostile, and administers the OS within compliance of the applied enterprise security policy. Table 13 - Objectives for the Operational Environment 4.3 Rationale for Security Objectives The table below describes how the assumptions, threats, and organizational security policies map to the security objectives. Threat, Assumption, or OSP Security Objectives Rationale T.NETWORK_ATTACK O.PROTECTED_COMMS, O.INTEGRITY, O.MANAGEMENT O.ACCOUNTABILITY The threat T.NETWORK_ATTACK is countered by O.PROTECTED_COMMS as this provides for integrity of transmitted data. The threat T.NETWORK_ATTACK is countered by O.INTEGRITY as this provides for integrity of software that is installed onto the system from the network. The threat T.NETWORK_ATTACK is countered by O.MANAGEMENT as this provides for the ability to configure the OS to defend against network attack. The threat T.NETWORK_ATTACK is countered by O.ACCOUNTABILITY as this provides a mechanism for the OS to report behavior that may indicate a network attack has occurred. Page 24 of 68 Threat, Assumption, or OSP Security Objectives Rationale T.NETWORK_EAVESDROP O.PROTECTED_COMMS, O.MANAGEMENT The threat T.NETWORK_EAVESDROP is countered by O.PROTECTED_COMMS as this provides for confidentiality of transmitted data. The threat T.NETWORK_EAVESDROP is countered by O.MANAGEMENT as this provides for the ability to configure the OS to protect the confidentiality of its transmitted data. T.LOCAL_ATTACK O.INTEGRITY O.ACCOUNTABILITY The objective O.INTEGRITY protects against the use of mechanisms that weaken the TOE with regard to attack by other software on the platform. The objective O.ACCOUNTABILITY protects against local attacks by providing a mechanism to report behavior that may indicate a local attack is occurring or has occurred. T.LIMITED_PHYSICAL_ACCESS O.PROTECTED_STORAGE The objective O.PROTECTED_STORAGE protects against unauthorized attempts to access physical storage used by the TOE. A.PLATFORM OE.PLATFORM The operational environment objective OE.PLATFORM is realized through A.PLATFORM. A.PROPER_USER OE.PROPER_USER The operational environment objective OE.PROPER_USER is realized through A.PROPER_USER. A.PROPER_ADMIN OE.PROPER_ADMIN The operational environment objective OE.PROPER_ADMIN is realized through A.PROPER_ADMIN. Table 14 - Rationale for Security Objectives Page 25 of 68 5 Extended Security Functional Components 5.1 List of Extended Security Functional Components Requirements Descriptions FCS_CKM_EXT.4 Cryptographic Key Destruction FCS_RBG_EXT.1 Random Bit Generation FCS_STO_EXT.1 Storage of Sensitive Data FCS_SSH_EXT.1 SSH Protocol FCS_SSHC_EXT.1 SSH Protocol - Client FCS_SSHS_EXT.1 SSH Protocol - Server FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.5 TLS Client Support for Supported Groups Extension FDP_IFC_EXT.1 Information flow control FDP_ACF_EXT.1 Access Controls for Protecting User Data FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT.2 X.509 Certificate Authentication FMT_MOF_EXT.1 Management of security functions behavior FMT_SMF_EXT.1 Specification of Management Functions FPT_ACF_EXT.1 Access controls FPT_ASLR_EXT.1 Address Space Layout Randomization FPT_SBOP_EXT.1 Stack Buffer Overflow Protection FPT_TST_EXT.1 Boot Integrity FPT_TUD_EXT.1 Trusted Update FPT_TUD_EXT.2 Trusted Update for Application Software FTP_ITC_EXT.1 Trusted channel communication Table 15 - Extended Security Functional Components 5.2 Extended Security Functional Components Rationale The definition of all SFRs with the appendix of "_EXT" is supplied by the protection profile. All extended security functional components are derived directly from the [GPOSPP], [PKG_SSH] and [PKG_TLS], and are applied verbatim. Please refer to Section 9 Annex B - Extended Security Functional Components. Page 26 of 68 6 Security Requirements 6.1 List of TOE Security Functional Requirements This section identifies the Security Functional Requirements for the TOE. The Security Functional Requirements included in this section are derived from Part 2 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5, dated: April 2017 and all international interpretations. Requirements Descriptions FAU_GEN.1 Audit Data Generation (Refined) FCS_CKM.1 Cryptographic Key Generation (Refined) FCS_CKM.2 Cryptographic Key Establishment (Refined) FCS_CKM_EXT.4 Cryptographic Key Destruction FCS_COP.1/ENCRYPT Cryptographic Operation - Encryption/Decryption (Refined) FCS_COP.1/HASH Cryptographic Operation - Hashing (Refined) FCS_COP.1/SIGN Cryptographic Operation - Signing (Refined) FCS_COP.1/KEYHMAC Cryptographic Operation - Keyed-Hash Message Authentication (Refined) FCS_RBG_EXT.1 Random Bit Generation FCS_STO_EXT.1 Storage of Sensitive Data FCS_SSH_EXT.1 SSH Protocol FCS_SSHC_EXT.1 SSH Protocol - Client FCS_SSHS_EXT.1 SSH Protocol - Server FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.5 TLS Client Support for Supported Groups Extension FDP_IFC_EXT.1 Information flow control FDP_ACF_EXT.1 Access Controls for Protecting User Data FIA_AFL.1 Authentication Failure Management (Refined FIA_UAU.5 Multiple Authentication Mechanisms (Refined) FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT.2 X.509 Certificate Authentication FMT_MOF_EXT.1 Management of security functions behavior FMT_SMF_EXT.1 Specification of Management Functions FPT_ACF_EXT.1 Access controls FPT_ASLR_EXT.1 Address Space Layout Randomization FPT_SBOP_EXT.1 Stack Buffer Overflow Protection FPT_TST_EXT.1 Boot Integrity FPT_TUD_EXT.1 Trusted Update FPT_TUD_EXT.2 Trusted Update for Application Software FTP_ITC_EXT.1 Trusted channel communication FTP_TRP.1 Trusted Path Table 16 - SFRs Page 27 of 68 6.2 Conventions The CC defines operations on Security Functional Requirements: assignments, selections, assignments within selections and refinements. This document uses the following font conventions to identify the operations defined by the CC: • Assignment: Indicated with italicized text; • Refinement: Indicated with bold text or strikethrough text; • Selection: Indicated with italicized and underlined text; • Iteration: Indicated by appending the SFR name with an additional identifier after ‘/’, e.g. FCS_COP.1/ENCRYPT • Where operations were completed in the PP or FP itself, the formatting used in the PP or FP has been retained. • Extended SFRs are identified by the addition of “EXT” after the requirement name. Extended SFRs are identified by having a label ‘EXT’ after the requirement name. Formatting conventions outside of operations matches the formatting specified within the PP or FP. 6.3 Security Functional requirements2 6.3.1 Security Audit (FAU) 6.3.1.1 FAU_GEN.1 Audit Data Generation (Refined) FAU_GEN.1.1 The OS shall be able to generate an audit record of the following auditable events: a. Start-up and shut-down of the audit functions; b. All auditable events for the [not specified] level of audit; and [ c. o Authentication events (Success/Failure); o Use of privileged/special rights events (Successful and unsuccessful security, audit, and configuration changes); o Privilege or role escalation events (Success/Failure); o [no other specifically defined auditable events]3 ] ]. FAU_GEN.1.2 The OS shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity (if applicable), and outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [User identity (if applicable)]. 2 The rationale for security functional requirements is stated in [GPOSPP] and is not reproduced in this ST. 3 For the auditable events listed in [PKG_SSH] all selections are completed with “None” (i.e. no audit requirements from [PKG_SSH] are selected). Page 28 of 68 6.3.2 Cryptographic Support (FCS) 6.3.2.1 FCS_CKM.1 Cryptographic Key Generation (Refined)4 FCS_CKM.1.1 The OS shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm: [ • RSA schemes using cryptographic key sizes of 3072-bit or greater that meet the following: FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Appendix B.3, • ECC schemes using "NIST curves" P-384 and [P-521] that meet the following: FIPS PUB 186-5, "Digital Signature Standard (DSS)", Appendix B.4, • FFC Schemes using [safe primes that meet the following: ‘NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes]. ]. 6.3.2.2 FCS_CKM.2 Cryptographic Key Establishment (Refined) FCS_CKM.2.1 The OS shall implement functionality to perform cryptographic key establishment in accordance with a specified cryptographic key establishment method:[ • Elliptic curve-based key establishment schemes that meets the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”, • Finite field-based key establishment schemes that meets the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” ]. 6.3.2.3 FCS_CKM_EXT.4 Cryptographic Key Destruction FCS_CKM_EXT.4.1 The OS shall destroy cryptographic keys and key material in accordance with a specified cryptographic key destruction method [ • For volatile memory, the destruction shall be executed by a [ o removal of power to the memory ] • For non-volatile memory that consists of [the invocation of an interface provided by the underlying platform that [ o instructs the underlying platform to destroy the abstraction that represents the key] ] ]. FCS_CKM_EXT.4.2 The OS shall destroy all keys and key material when no longer needed. 4 TD0712 is not applied, as Bluetooth functions are not claimed. Page 29 of 68 6.3.2.4 FCS_COP.1/ENCRYPT Cryptographic Operation - Encryption/Decryption (Refined) FCS_COP.1.1/ENCRYPT The OS shall perform [encryption/decryption services for data] in accordance with a specified cryptographic algorithm [ • AES-CBC (as defined in NIST SP 800-38A), • AES-CTR (as defined in NIST SP 800-38A) ] and [ AES-GCMP-256 (as defined in NIST SP 800-38D and IEEE 802.11ac-2013),] and cryptographic key sizes 256-bit that meet the following: [assignment: list of standards]. 6.3.2.5 FCS_COP.1/HASH Cryptographic Operation - Hashing (Refined)5 FCS_COP.1.1/HASH The OS shall perform [cryptographic hashing services] in accordance with a specified cryptographic algorithm [ • SHA-256, • SHA-384, • SHA-512] and message digest sizes [ • 256 bits, • 384 bits, • 512 bits] that meet the following: [FIPS Pub 180-4]. 6.3.2.6 FCS_COP.1/SIGN Cryptographic Operation - Signing (Refined)6 FCS_COP.1.1/SIGN The OS shall perform [cryptographic signature services (generation and verification)] in accordance with a specified cryptographic algorithm [ • RSA schemes using cryptographic key sizes of [3072-bit or greater] that meet the following: FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 4, • ECDSA schemes using "NIST curves" P-384 and [P-521] that meet the following: SP 800-186 Section 3. ] and cryptographic key sizes [assignment: cryptographic algorithm] that meet the following: [assignment: list of standards]. 5 TD0696 has been applied. 6 TD0873 has been applied Page 30 of 68 6.3.2.7 FCS_COP.1/KEYHMAC Cryptographic Operation - Keyed-Hash Message Authentication (Refined)7 FCS_COP.1.1/KEYMAC The OS shall perform [keyed-hash message authentication services] in accordance with a specified cryptographic algorithm [SHA-256, SHA-384, SHA-512] with key sizes [112 bits used in HMAC] and message digest sizes [256 bits, 384 bits, 512 bits] that meet the following: FIPS Pub 198-1 The Keyed-Hash Message Authentication Code and FIPS Pub 180-4 Secure Hash Standard. 6.3.2.8 FCS_RBG_EXT.1 Random Bit Generation FCS_RBG_EXT.1.1 The OS shall perform all deterministic random bit generation (DRBG) services in accordance with NIST Special Publication 800-90A using [ • CTR_DRBG (AES) ]. FCS_RBG_EXT.1.2 The deterministic RBG used by the OS shall be seeded by an entropy source that accumulates entropy from a [ • platform-based noise source ] with a minimum of 256 bits of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate. 6.3.2.9 FCS_STO_EXT.1 Storage of Sensitive Data FCS_STO_EXT.1.1 The OS shall implement functionality to encrypt sensitive data stored in non-volatile storage and provide interfaces to applications to invoke this functionality. 6.3.2.10 FCS_SSH_EXT.1 SSH Protocol FCS_SSH_EXT.1.1 The TOE shall implement SSH acting as a [client, server] in accordance with that complies with RFCs 4251, 4252, 4253, 4254, [4344, 5656, 6668, 8332] and [no other standard]. FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following authentication methods: [ • “password” (RFC 4252), • “publickey” (RFC 4252): [ o rsa-sha2-256 (RFC 8332) o rsa-sha2-512 (RFC 8332) o ecdsa-sha2-nistp384 (RFC 5656), o ecdsa-sha2-nistp521 (RFC 5656) ] ] and no other methods. 7 TD0696 has been applied. Page 31 of 68 FCS_SSH_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [262144] in an SSH transport connection are dropped. FCS_SSH_EXT.1.4 The TSF shall protect data in transit from unauthorised disclosure using the following mechanisms: [ • aes256-ctr (RFC 4344). ] and no other mechanisms. FCS_SSH_EXT.1.5 The TSF shall protect data in transit from modification, deletion, and insertion using: [ • hmac-sha2-256 (RFC 6668), • hmac-sha2-512 (RFC 6668), ] and no other mechanisms. FCS_SSH_EXT.1.6 The TSF shall establish a shared secret with its peer using:[ • ecdh-sha2-nistp384 (RFC 5656), • ecdh-sha2-nistp521 (RFC 5656) ] and no other mechanisms. FCS_SSH_EXT.1.7 The TSF shall use SSH KDF as defined in [ • RFC 4253 (Section 7.2), • RFC 5656 (Section 4), ] to derive the following cryptographic keys from a shared secret: session keys. FCS_SSH_EXT.1.8 The TSF shall ensure that [ • a rekey of the session keys ] occurs when any of the following thresholds are met: • one hour connection time • no more than one gigabyte of transmitted data, or • no more than one gigabyte of received data. 6.3.2.11 FCS_SSHC_EXT.1 SSH Protocol - Client FCS_SSHC_EXT.1.1 The TSF shall authenticate its peer (SSH server) using: [ • using a local database by associating each host name with a public key corresponding to the following list: [ o rsa-sha2-256 (RFC 8332), o rsa-sha2-512 (RFC 8332), o ecdsa-sha2-nistp384 (RFC 5656), o ecdsa-sha2-nistp521 (RFC 5656) ] Page 32 of 68 ] as described in RFC 4251 section 4.1. 6.3.2.12 FCS_SSHS_EXT.1 SSH Protocol – Server FCS_SSHS_EXT.1.1 The TSF shall authenticate itself to its peer (SSH Client) using: [ • rsa-sha2-256 (RFC 8332), • rsa-sha2-512 (RFC 8332), • ecdsa-sha2-nistp384 (RFC 5656), • ecdsa-sha2-nistp521 (RFC 5656) ]. 6.3.2.13 FCS_TLS_EXT.1 TLS Protocol FCS_TLS_EXT.1 .1The product shall implement [ • TLS as a client ]. 6.3.2.14 FCS_TLSC_EXT.1 TLS Client Protocol8 FCS_TLSC_EXT.1.1 The product shall implement TLS 1.2 (RFC 5246) and [no earlier TLS versions] as a client supporting the following cipher suites: [ • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 ] and also supports functionality for • none ]. FCS_TLSC_EXT.1.2 The product shall verify that the presented identifier matches the reference identifier per RFC 6125. FCS_TLSC_EXT.1.3 The product shall not establish a trusted channel if the server certificate is invalid [ • with no exceptions ] 8 [PKG_TLS] abbreviates Galois Counter Mode as GCM, whereas [GPOSPP] uses GCMP in its functional components. Page 33 of 68 6.3.2.15 FCS_TLSC_EXT.5 TLC Client Support for Supported Groups Extension FCS_TLSC_EXT.5.1 The product shall present the Supported Groups Extension in the Client Hello with supported groups: [secp384r1, secp521r1]. 6.3.3 User Data Protection (FDP) 6.3.3.1 FDP_ACF_EXT.1 Access Controls for Protecting User Data FDP_ACF_EXT.1.1 The OS shall implement access controls which can prohibit unprivileged users from accessing files and directories owned by other users. 6.3.3.2 FDP_IFC_EXT.1 Information flow control FDP_IFC_EXT.1.1 The OS shall [provide an interface which allows a VPN client to protect all IP traffic using IPsec] with the exception of IP traffic required to establish the VPN connection and [no other traffic]. 6.3.4 Identification and Authentication (FIA) 6.3.4.1 FIA_AFL.1 Authentication Failure Management (Refined) FIA_AFL.1.1 The OS shall detect when [ • an Administrator configurable positive integer within [1-65535] ] unsuccessful authentication attempts occur related to events with [ • authentication based on user name and password ]. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts for an account has been met, the OS shall: [Account Lockout]. 6.3.4.2 FIA_UAU.5 Multiple Authentication Mechanisms (Refined) FIA_UAU.5.1 The OS shall provide the following authentication mechanisms [ • authentication based on user name and password, • for use in SSH only, SSH public key based authentication as specified by the Functional Package for Secure Shell [PKG_SSH] ] to support user authentication. FIA_UAU.5.2 The OS shall authenticate any user's claimed identity according to the [authentication on the local console is based on user name and password, authentication via the SSHv2 protocol first performs the public key based authentication which is followed by the user name and password authentication if the public key based authentication was unsuccessful]. 6.3.4.3 FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT.1.1 Page 34 of 68 The OS shall implement functionality to validate certificates in accordance with the following rules: • RFC 5280 certificate validation and certificate path validation • The certificate path must terminate with a trusted CA certificate • The OS shall validate a certificate path by ensuring the presence of the basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and that any path constraints are met. • The TSF shall validate that any CA certificate includes "Certificate Signing" as a purpose in the key usage field • The OS shall validate the revocation status of the certificate using [CRL as specified in RFC 8603] with [no exceptions]. • The OS shall validate the extendedKeyUsage field according to the following rules: o Certificates used for trusted updates and executable code integrity verification shall have the Code Signing Purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field. o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the EKU field. o S/MIME certificates presented for email encryption and signature shall have the Email Protection purpose (id-kp 4 with OID 1.3.6.1.5.5.7.3.4) in the EKU field. o OCSP certificates presented for OCSP responses shall have the OCSP Signing Purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the EKU field. o Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the EKU field. FIA_X509_EXT.1.2 The OS shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. 6.3.4.4 FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.2.1 The OS shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [TLS] connections.9 9 TD0789 has been applied. Page 35 of 68 6.3.5 Security Management (FMT) 6.3.5.1 FMT_MOF_EXT.1 Management of security functions behavior FMT_MOF_EXT.1.1 The OS shall restrict the ability to perform the function indicated in the "Administrator" column in FMT_SMF_EXT.1.1 to the administrator. 6.3.5.2 FMT_SMF_EXT.1 Specification of Management Functions FMT_SMF_EXT.1.1 The OS shall be capable of performing the following management functions: Management Function Administrator10 User Enable/disable [session timeout] M Configure [session] inactivity timeout M Configure local audit storage capacity M Configure minimum password Length M Configure minimum number of special characters in password M Configure minimum number of numeric characters in password M Configure minimum number of uppercase characters in password M Configure minimum number of lowercase characters in password M Configure lockout policy for unsuccessful authentication attempts through [limiting number of attempts during a time period] M Configure host-based firewall M Configure name/address of directory server with which to bind Configure name/address of remote management server from which to receive management settings Configure name/address of audit/logging server to which to send audit/logging records M Configure audit rules M 10 TD0693 Changed use of “X” to “M”. Page 36 of 68 Management Function Administrator10 User Configure name/address of network time server M Enable/disable automatic software update M Configure WiFi interface Enable/disable Bluetooth interface Enable/disable [no other devices] No other management functions Table 17 - Specification of Management Functions 6.3.6 Protection of the TSF (FPT) 6.3.6.1 FPT_ACF_EXT.1 Access controls FPT_ACF_EXT.1.1 The OS shall implement access controls which prohibit unprivileged users from modifying: • Kernel and its drivers/modules • Security audit logs • Shared libraries • System executables • System configuration files • [no other objects]. FPT_ACF_EXT.1.2 The OS shall implement access controls which prohibit unprivileged users from reading: • Security audit logs • System-wide credential repositories • [no other objects]. 6.3.6.2 FPT_ASLR_EXT.1 Address Space Layout Randomization FPT_ASLR_EXT.1.1 The OS shall always randomize process address space memory locations with [32] bits of entropy except for [the Linux kernel, non-Position-Independent-Executable applications, non- Position-Independent-Code shared libraries]. 6.3.6.3 FPT_SBOP_EXT.1 Stack Buffer Overflow Protection FPT_SBOP_EXT.1.1 The OS shall [employ stack-based buffer overflow protections]. Page 37 of 68 6.3.6.4 FPT_TST_EXT.1 Boot Integrity FPT_TST_EXT.1.1 The OS shall verify the integrity of the bootchain up through the OS kernel and [ • no other executable code ] prior to its execution through the use of [ • a digital signature using a hardware-protected asymmetric key ]. 6.3.6.5 FPT_TUD_EXT.1 Trusted Update FPT_TUD_EXT.1.1 The OS shall provide the ability to check for updates to the OS software itself and shall use a digital signature scheme specified in FCS_COP.1/SIGN to validate the authenticity of the response. FPT_TUD_EXT.1.2 The OS shall [cryptographically verify] updates to itself using a digital signature prior to installation using schemes specified in FCS_COP.1/SIGN. 6.3.6.6 FPT_TUD_EXT.2 Trusted Update for Application Software FPT_TUD_EXT.2.1 The OS shall provide the ability to check for updates to application software and shall use a digital signature scheme specified in FCS_COP.1/SIGN to validate the authenticity of the response. FPT_TUD_EXT.2.2 The OS shall cryptographically verify the integrity of updates to applications using a digital signature specified by FCS_COP.1/SIGN prior to installation. 6.3.7 Trusted path/channels (FTP) 6.3.7.1 FTP_ITC_EXT.1 Trusted channel communication FTP_ITC_EXT.1.1 The OS shall use [ • TLS as conforming to Functional Package for Transport Layer Security version 1.1 as a [client] • SSH as conforming to the Functional Package for Secure Shell version 1.0 as a [client] ] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: [server] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data. 6.3.7.2 FTP_TRP.1 Trusted Path FTP_TRP.1.1 The OS shall provide a communication path between itself and [remote, local] users that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from modification and disclosure. FTP_TRP.1.2 The OS shall permit [the TSF, local users, remote users] to initiate communication via the trusted path. FTP_TRP.1.3 The OS shall require use of the trusted path for [initial user authentication, [all remote administrative actions]. Page 38 of 68 6.4 TOE SFR Dependencies Rationale for SFRs [GPOSPP], [PKG_SSH] and [PKG_TLS] contain all the requirements claimed in this Security Target. As such, the dependencies are not applicable since the PP and FP have been approved. 6.5 Security Assurance Requirements The TOE assurance requirements for this ST are taken directly from [GPOSPP] which are derived from Common Criteria Version 3.1, Revision 5. The assurance requirements are summarized in the table below. Assurance Class Components Components Description Development ADV_FSP.1 Basic Functional Specification Guidance Documentation AGD_OPE.1 Operational User Guidance AGD_PRE.1 Preparative Procedures Life-Cycle Support ALC_CMC.1 Labeling of the TOE ALC_CMS.1 TOE CM Coverage ALC_TSU_EXT.1 Timely Security Updates Tests ATE_IND.1 Independent Testing – Conformance Vulnerability Assessment AVA_VAN.1 Vulnerability Survey Table 18 - Security Assurance Requirements 6.6 Rationale for Security Assurance Requirements The functional specification describes the external interfaces of the TOE; such as the means for a user to invoke a service and the corresponding response of those services. The description includes the interface(s) that enforces a security functional requirement, the interface(s) that supports the enforcement of a security functional requirement, and the interface(s) that does not enforce any security functional requirements. The interfaces are described in terms of their purpose (general goal of the interface), method of use (how the interface is to be used), parameters (explicit inputs to and outputs from an interface that control the behavior of that interface), parameter descriptions (tells what the parameter is in some meaningful way), and error messages (identifies the condition that generated it, what the message is, and the meaning of any error codes). The development evidence also contains a tracing of the interfaces to the SFRs described in this ST. 6.7 Assurance Measures The TOE satisfies the identified assurance requirements. This section identifies the Assurance Measures applied by Oracle to satisfy the assurance requirements. The table below lists the details. SAR Component How the SAR will be met ADV_FSP.1 The functional specification describes the external interfaces of the TOE; such as the means for a user to invoke a service and the corresponding response of those services. The description includes the interface(s) that enforces a security functional requirement, the interface(s) that supports the enforcement of a security functional requirement, and the interface(s) that does not enforce any security functional Page 39 of 68 SAR Component How the SAR will be met requirements. The interfaces are described in terms of their purpose (general goal of the interface), method of use (how the interface is to be used), parameters (explicit inputs to and outputs from an interface that control the behavior of that interface), parameter descriptions (tells what the parameter is in some meaningful way), and error messages (identifies the condition that generated it, what the message is, and the meaning of any error codes). AGD_OPE.1 The Administrative Guide provides the descriptions of the processes and procedures of how the administrative users of the TOE can securely administer the TOE using the interfaces that provide the features and functions detailed in the guidance. AGD_PRE.1 The Installation Guide describes the installation, generation, and startup procedures so that the users of the TOE can put the components of the TOE in the evaluated configuration. ALC_CMC.1 The Configuration Management (CM) documents describe how the consumer identifies the evaluated TOE. The CM documents identify the configuration items, how those configuration items are uniquely identified, and the adequacy of the procedures that are used to control and track changes that are made to the TOE. This includes details on what changes are tracked and how potential changes are incorporated. ALC_CMS.1 ALC_TSU_EXT.1 The security updates are flagged as Critical or High based on the CSS ratings and should be available to the public within 24 hours of the fix has been finalized. Oracle uses the utilizes CVSS 3.0 specification for scoring CVEs. Any low severity CVEs will be evaluated in the next release based on priority. For the kernel, there will be quarterly release for the UEK. Any low severity may be addressed in the next major release. In addition, there is also a monthly errata for UEK where pending high level security issues can be consolidated. To report, security vulnerabilities, users should follow the process outline in the following website: https://www.oracle.com/corporate/security- practices/assurance/vulnerability/reporting.html The following webpage provides links to published Errata where users can track any vulnerabilities. https://linux.oracle.com/security/ If there is a publicly known vulnerability, users can track progress on the remediation progress from the following link: https://linux.oracle.com/security One can search for CVEs or Oracle Linux 9.3 Security Errata. Users can sign up to the mailing list to be notified of security updates: Page 40 of 68 SAR Component How the SAR will be met https://oss.oracle.com/mailman/listinfo/el-errata to receive updates. Oracle customers and partners should use the “My Oracle Support to submit a service request for any security vulnerabilities that they may have discovered in the Oracle product. All other users, should submit an email to secalert_us@oracle.com with their observations. All users are strongly recommended to use email encryption using Oracle encryption key when contacting Oracle Security. Oracle works closely with the research community who find vulnerabilities and work with Oracle so that the security fixes can be issued to all customers. ATE_IND.1 Oracle will provide the TOE for testing. AVA_VAN.1 Oracle will provide the TOE for testing. Table 19 - TOE Security Assurance Measures Page 41 of 68 7 TOE Summary Specification This chapter identifies and describes how the Security Functional Requirements and Security Assurance Requirements identified above are met by the TOE. TOE SFRs Rationale FAU_GEN.1 and FAU_GEN.2 The TOE leverages the Lightweight Audit Framework (LAF) audit system. Audit events are generated for the following audit functions: • Start-up and shut-down of the audit functions; • Authentication events (Success/Failure); • Use of privileged/special rights events (Successful and unsuccessful security, audit, and configuration changes) • Privilege or role escalation events (Success/Failure) Each audit record contains the following information: Date and time of the event, type of event, subject identity (if applicable), and outcome (success or failure) of the event The audit trail is stored in files which are only accessible by administrators. Once the audit files are full, the administrator would be notified. Once the audit trail is full, the audit daemon will not allow new audit events from the kernel. The kernel buffer must be cleared before new audit events are allowed. FCS_CKM.1 The TOE supports RSA key sizes of 3072 and 4096 bits for key generation conforming to FIPS PUB 186-5 Digital Signature Standard (DSS), Appendix B.3. The RSA keys are used in support of digital signatures for both TLS and SSH communications. The TOE supports ECC schemes using "NIST curves" P-384 and P-521 that meet the following: FIPS PUB 186-5, "Digital Signature Standard (DSS)", Appendix B.4. ECDSA is used in support of TLS and SSH communications. FFC Schemes using safe primes that meet the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes” for use in TLS. Please refer to Table 4 Cryptographic Algorithm Certificates for NIST CAVPs for RSA, and ECDSA. FCS_CKM.2 The TOE supports Cryptographic Key Establishment using the following schemes: • Elliptic curve-based key establishment schemes that meets the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”. Page 42 of 68 TOE SFRs Rationale • Finite field-based key establishment conforming to NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”. Please refer to Table 4 Cryptographic Algorithm Certificates for NIST CAVPs for ECDSA and KAS/CVL FCC. FCS_CKM_EXT.4 For volatile memory, the destruction is executed by removal of power to the memory. For non-volatile memory, the destruction consists of the invocation of an interface provided by the underlying platform that instructs the underlying platform to destroy the abstraction that represents the key. Symmetric key material and Diffie-Hellman / EC Diffie-Hellman public and private keys are derived using the SSH KDF and stored in volatile memory. Asymmetric key material is stored on hard disk. The /etc/ssh directory contains the host keys which are generated using ssh-keygen. The $HOME/.ssh contains user keys and are generated using ssh-keygen. Authorized public keys are generated remotely and input into the TOE. Symmetric session keys for TLS are derived from the TLS KDF. FCS_COP.1/ENCRYP T The TOE supports AES encryption and decryption conforming to • CBC as specified in NIST SP 800-38A • CTR as specified in NIST SP 800-38A • GCMP as specified in NIST SP 800-38D and IEEE 802.11ac-2013 The AES key size supported is 256 bits and the AES modes supported are: CBC, CTR and GCM. The SSH software performs encryption/decryption services for data in accordance with a specified cryptographic algorithm AES-CTR (as defined in NIST SP 800-38A) mode and cryptographic key size of 256-bits. The TSF provides unique counter values for the AES-CTR algorithm. The OpenSSH module uses the OpenSSL module which does the AES CTR for SSH. A normal sequence of events would be to call ssh_aes_ctr_init() when a session is started, multiple calls to ssh_aes_ctr() to encrypt packets, and ssh_aes_ctr_cleanup to close out a session and free memory. The ssh_aes_ctr_init() function accepts a key and iv for the session (the iv is used as the initial value for the ctr). If the calling program (ssh or sshd) supplies an IV (ctr), it is used as the initial value for the counter, otherwise 0 is the initial value used. As encryption is done the with the ssh_aes_ctr function, the ssh_ctr_inc is called to increment the value of the counter by 1. Because the counter value is 128 bits (16 bytes), there is no direct instruction to add 1 to it, so the ssh_ctr_inc function does a loop to increment the value byte-by-byte and handles carries from low-order bytes to high-order bytes. Page 43 of 68 TOE SFRs Rationale Since the counter is 128 bits, it would take a HUGE amount of time before a ctr value is re-used with a specific key because of roll-over. AES_GCMP is used in support of TLS (see entry for FCS_TLSC_EXT.1). AES encryption (all modes) is used in support of file encryption (see FCS_STO_EXT.1). Please refer to Table 4 Cryptographic Algorithm Certificates for NIST CAVPs for AES. FCS_COP.1/HASH11 The TOE supports Cryptographic hashing services conforming to FIPS Pub 180-4. The hashing services are used for: • Signature services (FCS_COP.1/SIGN) • HMAC services (FCS_COP.1/KEYHMAC • SSH (FCS_SSH_EXT.1, FCS_SSHC_EXT.1) • TLS (FCS_TLSC_EXT.1) • Boot integrity (FPT_TST_EXT.1) • Trusted updates ( FPT_TUD_EXT.1, FPT_TUD_EXT.2) The hashing algorithms supported for the above services are: SHA-256, SHA-384 and SHA-512. The message digest sizes supported for the above services are: 256 bits, 384 bits and 512 bits. Please refer to Table 4 Cryptographic Algorithm Certificates for NIST CAVPs SHS. FCS_COP.1/SIGN The TOE provides Cryptographic signature generation and verification in accordance with the following cryptographic algorithms: • RSA digital signature algorithm conforming to FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Section 4. • The RSA key sizes supported are: 3072 and 4096 bits. • ECDSA schemes using "NIST curves" P-384 and [P-521] that meet the following: FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 5 • The Elliptical curve key size supported is 256 bits. Please refer to Table 4 Cryptographic Algorithm Certificates for NIST CAVPs for RSA. FCS_COP.1/KEYHMA C The TOE supports Keyed-hash message authentication conforming to the Keyed- Hash Message Authentication Code and FIPS Pub 180-4 Secure Hash Standard with the following algorithms: 11 TD0696 has been applied. Page 44 of 68 TOE SFRs Rationale • Keyed hash algorithm authentication services in accordance with the following specified cryptographic algorithms: SHA-256, SHA-384 and SHA-512. • Key sizes supported are: 112 bits. HMAC algorithms is used in support of TLS and SSH sessions. HMAC Algorithms Hash Functions Block Size Key lengths MAC lengths HMAC-SHA- 256 SHA-256 512 bits 256 bits 256 bits HMAC-SHA- 384 SHA-384 1024 bits 384 bits 384 bits HMAC-SHA- 512 SHA-512 1024 bits 512 bits 512 bits Please refer to Table 4 Cryptographic Algorithm Certificates for NIST CAVPs for HMAC. FCS_RBG_EXT.1 The TOE uses the following DRBG conforming to NIST Special Publication 800- 90A: • CTR_DRBG(AES) The TOE leverages CTR_DRBG (AES). The deterministic RBG used by the OS is seeded by an entropy source that accumulates entropy from a platform-based noise source with a minimum of 256 bits of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate. Please refer to Table 4 Cryptographic Algorithm Certificates for NIST CAVPs for DRBG. FCS_STO_EXT.1 The TOE includes the Oracle Linux 9.3 OpenSSL, which provides an interface to end-users to securely store sensitive data on the filesystem. OpenSSL provides file encryption services using AES-CBC and AES_CTR and with 256 bit key size. Sensitive data stored in the /etc directory are keys, user passwords and application credentials, along with system-wide configuration files and system databases. Strict file permissions and/or encryption ensure access only by the ‘root’ user and/or the application storing the sensitive data. FCS_SSH_EXT.1 The TOE SSH software implements the SSH protocol that complies with RFCs 4251, 4252, 4253, 4254, 4344, 5656, 6668, and 8332 as a client and server. FCS_SSH_EXT.1.2 The TOE supports password-based authentication (RFC 4252), and public key authentication (RFC 4252). Page 45 of 68 TOE SFRs Rationale The following public key algorithms are supported for authentication: rsa-sha2- 256 (RFC 8332), rsa-sha2-512 (RFC 8332), ecdsa-sha2-nistp384 (RFC 5656), and ecdsa-sha2-nistp521 (RFC 5656). This list conforms to FCS_SSH_EXT.1.2. FCS_SSH_EXT.1.3 The TOE ensures that SSH packets that exceed 262144 bytes are dropped at the application layer per RFC 4253. This large packet size is typical for Linux implementations. Once SSH packets are received, it is verified that it contains the packet length, padding length, payload and random padding. Once the packet information has been verified then the packet is decrypted. The packets are stored in a buffer. If the packet size is larger than permitted, the SSH packets are dropped, and the connection is terminated. FCS_SSH_EXT.1.4 The TOE supports the following encryption algorithm: aes256-ctr (RFC 4344). Optional characteristics are not supported. The encryption algorithms specified are identical to those listed for the component. FCS_SSH_EXT.1.5 The TOE supports the following data integrity HMAC algorithms: hmac-sha2-256 (RFC 6668) and hmac-sha2-512 (RFC 6668) Optional characteristics are not supported. The encryption algorithms specified are identical to those listed for the component. FCS_SSH_EXT.1.6 The TOE supports the following key exchange algorithms: ecdh-sha2-nistp384 (RFC 5656), and ecdh-sha2-nistp521 (RFC 5656). The key exchange algorithms specified are identical to those listed for the component. FCS_SSH_EXT.1.7 The TOE uses SSH KDF as defined in RFC 4253 (Section 7.2), and RFC 5656 (Section 4) to derive the following cryptographic keys from a shared secret: session keys. FCS_SSH_EXT.1.8 The TOE ensures that a rekey of the session keys occurs when any of the following thresholds are met: one hour connection time and no more than one gigabyte of transmitted data or no more than one gigabyte of received data. FCS_SSHC_EXT.1 The TOE authenticates its peer (SSH server) using a local database by associating each host name with a public key corresponding to the following: rsa-sha2-256 (RFC 8332), rsa-sha2-512 (RFC 8332), ecdsa-sha2-nistp384 (RFC 5656), and ecdsa-sha2-nistp521 (RFC 5656) as described in RFC 4251 section 4.1. FCS_SSHS_EXT.1 The TOE authenticates itself to its peer (SSH Client) using: rsa-sha2-256 (RFC 8332), rsa-sha2-512 (RFC 8332), ecdsa-sha2-nistp384 (RFC 5656), and ecdsa- sha2-nistp521 (RFC 5656). Page 46 of 68 TOE SFRs Rationale FCS_TLSC_EXT.1.1 The TOE implements TLS 1.2 (RFC 5246) supporting the following cipher suites: • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 The cipher suites specified are identical to those listed for this component. FCS_TLSC_EXT.1.2 The TOE verifies that the presented identifier matches the reference identifier according to RFC 6125. The following reference identifiers are to be verified during the TLS channel establishment: • DNS host name or IP address found in Common Name of the X.509 certificate. Wild cards are supported. • DNS host name found in the SAN for DNS names of the X.509 certificate. The TOE does not support URI reference identifiers, SRV reference identifiers, or certificate pinning. FCS_TLSC_EXT.1.3 The TOE establishes a trusted channel only if the peer certificate is valid. FCS_TLSC_EXT.5.1 The TOE shall present the Supported Groups Extension in the Client Hello with the supported groups: secp384r1, and secp521r1. FDP_ACF_EXT.1 The TOE provides support for POSIX type access control lists. ACL’s can be used with the following file systems: • ext4 • XFS • OCSFS2 An ACL consists of a set of rules that specify how a specific user or group can access the file or directory with which the ACL is associated. A regular ACL entry specifies access information for a single file or directory. A default ACL entry is set on directories only and specifies default access information for any file within the directory that does not have an access ACL. Users can configure ACLs that define access rights for more than just a single user or group, and specify rights for programs, processes, files, and directories. If you set a default ACL on a directory, its descendants inherit the same rights automatically. FDP_IFC_EXT.1 The TOE provides the XFRM framework with the XFRM netlink interface and it also provides the TUN/TAP interface for supporting user-space VPN clients operating at ISO/OSI level 2 or 3. IP traffic goes through the VPN, except traffic necessary to for establishing the VPN connection. IKE, HTTPS and DNS traffic may not go through the VPN. Page 47 of 68 TOE SFRs Rationale FIA_AFL.1 The TOE will detect when an administrator configurable integer within 1-65535 unsuccessful authentication attempts for authentication based on user name and password occur related to authentication on local console, and password- based authentication via SSH v2 protocol. Once the specified number of unsuccessful authentication attempts for an account has been met, the OS shall lock the account. FIA_UAU.5 The TOE supports authentication based on username and password and public key-based authentication. The TOE leverages the Pluggable Authentication Module (PAM) authentication mechanism. For password-based authentication, when the user provides the correct username and password, this is compared to the known user database and if they match then the user is granted access. Otherwise, the user will not be granted access to the TOE. ’When using key-based authentication, the user must generate an RSA key pair. If the user uses public key-based authentication, the presented key is compared to the user’s stored key. If the comparison is successful, then the user is granted access to the TOE. If the public key based authentication is unsuccessful, the user is prompted for a username and password. FIA_X509_EXT.1 When an X.509 certificate is presented, the TOE verifies the certificate path, and certification validation process by verifying the following rules: • RFC 5280 certificate validation and certificate path validation. • The certificate path must terminate with a trusted CA certificate. • The OS shall validate a certificate path by ensuring the presence of the basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and that any path constraints are met. • The TSF shall validate that any CA certificate includes caSigning purpose in the key usage field The TOE supports CRL as specified by RFC 5759. The OS shall validate the extendedKeyUsage field according to the following rules: o Certificates used for trusted updates and executable code integrity verification shall have the Code Signing Purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field. o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. Page 48 of 68 TOE SFRs Rationale o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the EKU field. o S/MIME certificates presented for email encryption and signature shall have the Email Protection purpose (id-kp 4 with OID 1.3.6.1.5.5.7.3.4) in the EKU field. o OCSP certificates presented for OCSP responses shall have the OCSP Signing Purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the EKU field. o Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the EKU field. (conditional) A Security Administrator can configure the TSF to use OCSP or CRL for revocation checking. The TOE validates X.509 certificates when presented as part of a TLS Server Hello during a handshake. FIA_X509_EXT.1.2 The TOE only treats a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. FIA_X509_EXT.2 The TOE uses X.509v3 certificates for TLS connections only. FMT_MOF_EXT.1 All management activities are restricted to the root user. Privileges to perform administrative actions are maintained by the TOE. These privileges are separated into privileges to act on data or access functionality in user space and in kernel space. Functionality accessible in user space are applications that can be invoked by users. Also, data accessible in user space is either data maintained with an application or data stored in persistent or transient storage objects. Privileges are controlled by permissions to invoke applications and to access data. For example, the configuration files including the user databases of /etc/passwd and /etc/shadow are accessible to the root user only. Due to privileges being controlled by permissions, this prevents users from performing management functions that they do not have access to. FMT_SMF_EXT.1 The TOE maintains the following roles: Administrator and User The management functions are listed below: Management Function Administrator User Enable/disable [session timeout] M Configure [session] inactivity timeout M Configure local audit storage capacity M Page 49 of 68 TOE SFRs Rationale Configure minimum password Length M Configure minimum number of special characters in password M Configure minimum number of numeric characters in password M Configure minimum number of uppercase characters in password M Configure minimum number of lowercase characters in password M Configure lockout policy for unsuccessful authentication attempts through [limiting number of attempts during a time period] M Configure host-based firewall M Configure name/address of audit/logging server to which to send audit/logging records M Configure audit rules M Configure name/address of network time server M Enable/disable automatic software update M FPT_ACF_EXT.1 The TOE implements access control to the following security relevant data: • /boot, /usr/lib/firmware, usr/lib/modules: contain kernel, kernel modules and device drivers • /var/log/audit, /var/log/secure: contain audit data • /usr/lib and /usr/lib64: contain shared libraries • /usr/bin, /usr/sbin, /usr/libexec: contain system executables • /etc, /usr/lib: contain system configuration files. This access control prohibits unprivileged users from reading security audit logs and system-wide credential repositories. FPT_ASLR_EXT.1 The TOE always randomizes process address memory locations with 32 bits of entropy except for the Linux kernel, non-Position-Independent-Executable applications, non-Position-Independent-Code shared libraries. Page 50 of 68 TOE SFRs Rationale FPT_SBOP_EXT.1 The TOE implements compiler flag stack-based buffer overflow protections. Application developers should use the following compiler options as best practice when developing applications invoking the gcc compiler and linker. The stack-protector-strong flag has been developed to broaden the scope of the stack protection without extending it to every function in the program. -fstack-protector-strong --param=ssp-buffer-size=4 ASLR improves executable security in terms of memory randomization and access protection. -fpie -Wl,-pie The following libraries come from the gawk package. The functions do not have an array on the stack, so they do not need stack protection. - /usr/lib64/gawk/revtwoway.so The following library comes from the glib2 package. The library only has a couple of functions, none of which need stack protection. - /usr/lib64/libgthread-2.0.so.0. 6800.4 The following libraries come from the glibc package. Package is built with -fstack- protector-strong and -fstack-clash-protection flags. - glibc has special needs (code for stack unwinding, exception handling, and other handwritten assembler): - /usr/lib64/libc.so.6 - /usr/lib64/ld-linux-x86-64.so.2 The harfbuzz package is built with -fstack-protector-strong and -fstack-clash- protection flags. The functions in this binary do not have an array on the stack so do not need stack protection. - /usr/lib64/libharfbuzz-gobject.so.0.20704.0 The functions in following binaries do not have an array on the stack so they do not need stack protection: - /usr/lib64/libanl.so.1 - /usr/lib64/libdl.so.2 - /usr/lib64/libmvec.so.1 - /usr/lib64/libnss_dns.so.2 - /usr/lib64/libnss_files.so.2 - /usr/lib64/libpthread.so.0 - /usr/lib64/librt.so.1 - /usr/lib64/libutil.so.1 - /usr/lib64/gconv/libCNS.so Page 51 of 68 TOE SFRs Rationale - /usr/lib64/gconv/libGB.so - /usr/lib64/gconv/libISOIR165.so - /usr/lib64/gconv/libJIS.so - /usr/lib64/gconv/libJISX0213.so - /usr/lib64/gconv/libKSC.so The following libraries come from the iptables package. Package is built with - fstack-protector-strong and -fstack-clash-protection flags. There are some functions on the following shared libraries that do define an array, however they are all static arrays: - /usr/lib64/xtables/libip6t_ah.so - /usr/lib64/xtables/libip6t_LOG.so - /usr/lib64/xtables/libip6t_SNAT.so - /usr/lib64/xtables/libip6t_srh.so - /usr/lib64/xtables/libipt_LOG.so - /usr/lib64/xtables/libipt_ULOG.so - /usr/lib64/xtables/libxt_cgroup.so - /usr/lib64/xtables/libxt_helper.so - /usr/lib64/xtables/libxt_HMARK.so - /usr/lib64/xtables/libxt_ipvs.so - /usr/lib64/xtables/libxt_nfacct.so - /usr/lib64/xtables/libxt_NFLOG.so - /usr/lib64/xtables/libxt_policy.so - /usr/lib64/xtables/libxt_recent.so - /usr/lib64/xtables/libxt_TEE.so - /usr/lib64/xtables/libxt_TPROXY.so - The following shared libraries do not use any functions that define arrays on the stack, so they do not need stack smashing protection: - /usr/lib64/xtables/libip6t_DNPT.so - /usr/lib64/xtables/libip6t_eui64.so - /usr/lib64/xtables/libip6t_frag.so - /usr/lib64/xtables/libip6t_hl.so - /usr/lib64/xtables/libip6t_HL.so - /usr/lib64/xtables/libip6t_ipv6header.so - /usr/lib64/xtables/libip6t_REJECT.so - /usr/lib64/xtables/libip6t_rt.so - /usr/lib64/xtables/libip6t_SNPT.so - /usr/lib64/xtables/libipt_ah.so - /usr/lib64/xtables/libipt_CLUSTERIP.so - /usr/lib64/xtables/libipt_ECN.so - /usr/lib64/xtables/libipt_REJECT.so - /usr/lib64/xtables/libipt_ttl.so - /usr/lib64/xtables/libipt_TTL.so - /usr/lib64/xtables/libxt_addrtype.so - /usr/lib64/xtables/libxt_AUDIT.so - /usr/lib64/xtables/libxt_CHECKSUM.so Page 52 of 68 TOE SFRs Rationale - /usr/lib64/xtables/libxt_cluster.so - /usr/lib64/xtables/libxt_connbytes.so - /usr/lib64/xtables/libxt_connmark.so - /usr/lib64/xtables/libxt_CONNMARK.so - /usr/lib64/xtables/libxt_CONNSECMARK.so - /usr/lib64/xtables/libxt_cpu.so - /usr/lib64/xtables/libxt_dccp.so - /usr/lib64/xtables/libxt_dscp.so - /usr/lib64/xtables/libxt_DSCP.so - /usr/lib64/xtables/libxt_ecn.so - /usr/lib64/xtables/libxt_esp.so - /usr/lib64/xtables/libxt_IDLETIMER.so - /usr/lib64/xtables/libxt_ipcomp.so - /usr/lib64/xtables/libxt_LED.so - /usr/lib64/xtables/libxt_length.so - /usr/lib64/xtables/libxt_mac.so - /usr/lib64/xtables/libxt_mark.so - /usr/lib64/xtables/libxt_multiport.so - /usr/lib64/xtables/libxt_NFQUEUE.so - /usr/lib64/xtables/libxt_osf.so - /usr/lib64/xtables/libxt_physdev.so - /usr/lib64/xtables/libxt_pkttype.so - /usr/lib64/xtables/libxt_quota.so - /usr/lib64/xtables/libxt_rpfilter.so - /usr/lib64/xtables/libxt_sctp.so - /usr/lib64/xtables/libxt_SECMARK.so - /usr/lib64/xtables/libxt_socket.so - /usr/lib64/xtables/libxt_standard.so - /usr/lib64/xtables/libxt_statistic.so - /usr/lib64/xtables/libxt_SYNPROXY.so - /usr/lib64/xtables/libxt_tcpmss.so - /usr/lib64/xtables/libxt_TCPMSS.so - /usr/lib64/xtables/libxt_tos.so - /usr/lib64/xtables/libxt_TOS.so - /usr/lib64/xtables/libxt_TRACE.so - /usr/lib64/xtables/libxt_udp.so - /usr/lib64/xtables/libebt_arpreply.so - /usr/lib64/xtables/libebt_dnat.so - /usr/lib64/xtables/libebt_redirect.so - /usr/lib64/xtables/libebt_snat.so The following libraries come from the kernel-modules-core package. Package is built with -fstack-protector-strong and -fstack-clash-protection flags. The following shared libraries do not use any function that defines arrays on the stack, so they do not need stack smashing protection: - /usr/lib/modules/5.15.0-300.163.18.el9uek.x86_64//vdso/vdso32.so - /usr/lib/modules/5.15.0-300.163.18.el9uek.x86_64//vdso/vdso64.so Page 53 of 68 TOE SFRs Rationale - /usr/lib/modules/5.14.0-427.37.1.el9_4.x86_64//vdso/vdso32.so - /usr/lib/modules/5.14.0-427.37.1.el9_4.x86_64//vdso/vdso64.so The following libraries come from the kernel-uek-core package. Package is built with -fstack-protector-strong and -fstack-clash-protection flags. The functions in the following shared libraries do not use any function that defines arrays on the stack, so they do not need stack smashing protection: - /usr/lib/modules/5.15.0-200.131.27.el9uek.x86_64/vdso/vdso32.so - /usr/lib/modules/5.15.0-200.131.27.el9uek.x86_64/vdso/vdso64.so The following libraries come from the libbrotli package. Package is built with - fstack-protector-strong and -fstack-clash-protection flags. The functions in the following binaries do not have an array on the stack so do not need stack protection: - /usr/lib64/libbrotlicommon.so.1.0.9 - /usr/lib64/libdrop_ambient.so.0.0.0 The following library come from the libcap package. Package is built with -fstack- protector-strong and -fstack-clash-protection flags. The functions in the following binary do not have an array on the stack so do not need stack protection: - /usr/lib64/libdrop_ambient.so.0.0.0 The following library come from the libgcc package. - Package is built with -fstack-protector-strong and -fstack-clash-protection flags - The functions in the following binary do not have an array on the stack so do not need stack protection: - /usr/lib64/libgcc_s-11-20230605.so.1 The following libraries come from the libldb package. - Package is built with -fstack-protector-strong and -fstack-clash-protection flags - The functions in following binaries do not have an array on the stack so they do not need stack protection: - /usr/lib64/ldb/libldb-tdb-err-map.so - /usr/lib64/ldb/modules/ldb/ldb.so - /usr/lib64/ldb/modules/ldb/mdb.so - /usr/lib64/ldb/modules/ldb/skel.so - /usr/lib64/ldb/modules/ldb/tdb.so The following libraries come from the libref_array package. Package is built with -fstack-protector-strong and -fstack-clash-protection flags. The functions in following binaries do not have an array on the stack so do not need stack protection: - /usr/lib64/libref_array.so.1.2.1 Page 54 of 68 TOE SFRs Rationale The following libraries come from the ncurses package. Package is built with - fstack-protector-strong and -fstack-clash-protection flags .The functions do not have an array on the stack, so they do not need stack protection: - /usr/lib64/libpanel.so.6.2 - /usr/lib64/libpanelw.so.6.2 The following libraries come from the openssl-libs-3.0.7 package. Package is built with -fstack-protector-strong and -fstack-clash-protection flags. The functions in following binary do not have an array on the stack so do not need stack protection: - /usr/lib64/engines-3/capi.so The following libraries come from the pam package. Package is built with -fstack- protector-strong and -fstack-clash-protection flags. The functions in the following binaries do not have an array on the stack so do not need stack protection: - /usr/lib64/security/pam_debug.so - /usr/lib64/security/pam_deny.so - /usr/lib64/security/pam_postgresok.so The following library comes from the python3 package. The library has a single simple function, no stack protection is needed: - /usr/lib64/libpython3.so The following library comes from the python3-cryptography package. Package is built with -fstack-protector-strong and -fstack-clash-protection flags. The functions in following binary do not have an array on the stack so do not need stack protection: - /usr/lib64/python3.9/site- packages/cryptography/hazmat/bindings/_rust.abi3.so The following library comes from the python3-libs package. Package is built with -fstack-protector-strong and -fstack-clash-protection flags. The functions in following binaries do not have an array on the stack so they do not need stack protection: - /usr/lib64/libpython3.so - /usr/lib64/python3.9/lib-dynload/_contextvars.cpython-39-x86_64-linux- gnu.so - /usr/lib64/python3.9/lib-dynload/_curses_panel.cpython-39-x86_64-linux- gnu.so - /usr/lib64/python3.9/lib-dynload/_heapq.cpython-39-x86_64-linux-gnu.so - /usr/lib64/python3.9/lib-dynload/_statistics.cpython-39-x86_64-linux- gnu.so The following library comes from the userspace-rcu package. Package is built with -fstack-protector-strong and -fstack-clash-protection flags. The functions in following binaries do not have an array on the stack so do not Page 55 of 68 TOE SFRs Rationale need stack protection: - /usr/lib64/liburcu-common.so.6.1.0 - /usr/lib64/libbd_part_err.so.2.0.0 - /usr/lib64/libplc4.so FPT_TST_EXT.1 When the OS boots, it performs the following operations: The computer's BIOS performs a power-on self-test (POST), and then locates and initializes any peripheral devices including the hard disk. The BIOS reads the Master Boot Record (MBR) into memory from the boot device. (For GUID Partition Table (GPT) disks, this MBR is the protective MBR on the first sector of the disk.) The MBR stores information about the organization of partitions on that device. On a computer with x86 architecture, the MBR occupies the first 512 bytes of the boot device. The first 446 bytes contain boot code that points to the boot loader program, which can be on the same device or on another device. The next 64 bytes contain the partition table. The final two bytes are the boot signature, which is used for error detection. The default boot loader program used on Oracle Linux is GRUB 2, which stands for Grand Unified Bootloader version 2. When Secure Boot is used there are two stages of bootloaders. The first stage bootloader starts and verifies the keys for GRUB2. Once the keys are verified GRUB2 is loaded. The boot loader loads the vmlinuz kernel image file into memory and extracts the contents of the initramfs image file into a temporary, memory-based file system (tmpfs). The kernel loads the driver modules from the initramfs file system that are needed to access the root file system. The kernel starts the systemd process with a process ID of 1 (PID 1). systemd is the ancestor of all processes on a system. systemd reads its configuration from files in the /etc/systemd directory. The /etc/systemd/system.conf file controls how systemd handles system initialization. During this process systemd mounts file systems, saves entropy, and starts system logging, and cron daemons. Known answer tests are run for the following cryptographic algorithms and cryptographic operations provided by the TOE: AES-CBC/AES-GCM SHA-256, SHA-384, SHA-512 HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 RSA Sign Verify ECDSA Sign Verify CVL SSH v2 CVL TLS v1.2 DRBG Page 56 of 68 TOE SFRs Rationale As a final step, the kernel executes /sbin/init. The OS uses Unified Extensible Firmware Interface (UEFI) Secure Boot technology to ensure the system firmware checks whether the system boot loader is signed with an authorized cryptographic key. The first-stage boot loader, shim.efi, is signed by a UEFI private key and authenticated by a public key, signed by a certificate authority (CA), stored in the firmware database. This boot loader also contains the Oracle public key, which is used to authenticate the GRUB 2 boot loader and the Oracle kernel. The kernel contains public keys to authenticate drivers and modules. Kernel Boot process • The kernel will carry out the following actions as part of the boot process: • Setup functions will be initialized and configure the hardware devices, then the kernel will be loaded into memory function. • Memory management will be initialized. • Kernel mode stack for process 0 is set. • The provisional Page Tables paging will be enabled. • Exception handlers would be set. The kernel will then complete the kernel initialization by initializing Page Tables, Memory Handling Data Structures, the SLUB allocator, system date, and system time. Once the kernel boot process is complete, the user space would be started up. The root file must be available along with the loading of applications and daemons. All other setup and configuration process to get the system operational would be carried out. The software is cryptographically verified (integrity tested) using HMAC-SHA-256. The HMAC value is computed at build time and stored in the hmac file. The value is recalculated at runtime and compared against the stored value. If the comparison succeeds, then the remaining power-up self-test (consisting of the algorithm-specific Known Answer Tests) are performed. On successful completion of the power-up tests, the module becomes operational and crypto services are available. If any of the tests fails module transitions to error state and subsequent calls to the Module will fail - thus no further cryptographic operations will be possible. FPT_TUD_EXT.1 FPT_TUD_EXT.2 The TOE software is delivered and installed using Red Hat Packages (RPMs). An Oracle certificate is used to verify the RPM during installation of an RPM. The Oracle certificate is installed on the system at the time of installation. The TOE leverages 4096 bit RSA digital signature mechanism for signing and verification of packages/updates. SHA-256 used for integrity verification. If the signature verification is successful, then the RPM package is installed. Otherwise, it fails the Page 57 of 68 TOE SFRs Rationale installation. The administrator must download the RPM from the Oracle download center. To obtain updates, the TOE pulls the latest update lists from Oracle servers nightly and either installs new RPMs automatically or informs the administrator about the presence of update RPMs, depending on the system configuration. The installation of these updates follows the signature verification procedure discussed above. FTP_ITC_EXT.1 The TOE supports TLS v1.2 and SSH v2 for trusted channel implementation. Further details on the implementation of these protocols is provided in FCS_TLSC_EXT.1 and FCS_SSHC_EXT.1. FTP_TRP.1 The TOE supports remote CLI using SSH v2 for secure remote administration. Administration via the local console is also supported. This access is logically distinct from other communication paths and is authenticated by the user prior to access being granted to administrate the OS. Data is protected from modification and disclosure through physical security. Local and remote access to the trusted path is initiated by the user or TSF. No other methods to administer the TOE are available. Table 20 - TOE Summary Specification SFR Description ALC_TSU_EXT.1 The information as to how the end-user devices are updated to address security issues in a timely manner is described in section 6.7, table 18 above. Table 21 - TOE Summary Specification SAR Description Page 58 of 68 8 Annex A: References Identifiers Descriptions [CC_PART1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general model, dated April 2017, version 3.1, Revision 5, CCMB-2017-04-001 [CC_PART2] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional components, dated April 2017, version 3.1, Revision 5, CCMB-2017-04-002 [CC_PART3] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance components, dated April 2017, version 3.1, Revision 5, CCMB-2017-04-003 [CEM] Common Methodology for Information Technology Security Evaluation – Evaluation Methodology, dated April 2017, version 3.1, Revision 5, CCMB-2017- 04-004 [800-56A] NIST Special Publication 800-56A Rev 2, May 2013 [800-38A] [NIST Special Publication 800-38A Recommendation for Block Cipher Modes of Operation: Methods and Techniques, December 2001 [800-38D] NIST Special Publication 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, November 2007. [PKG_SSH] Functional Package for Secure shell (SSH), NIAP, Version 1.0, 2021-05-13 [PKG_TLS] Functional Package for Transport Layer Security (TLS), NIAP, Version 1.1, 2019- 03-01 Table 22 - Annex A: References Page 59 of 68 9 Annex B - Extended Security Functional Components Requirements Descriptions FCS_CKM_EXT.4 Cryptographic Key Destruction FCS_RBG_EXT.1 Random Bit Generation FCS_STO_EXT.1 Storage of Sensitive Data FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.5 TLS Client Support for Supported Groups Extension FCS_SSH_EXT.1 SSH Protocol FCS_SSHC_EXT.1 SSH Protocol - Client FCS_SSHS_EXT.1 SSH Protocol - Server FDP_IFC_EXT.1 Information flow control FDP_ACF_EXT.1 Access Controls for Protecting User Data FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT.2 X.509 Certificate Authentication FMT_MOF_EXT.1 Management of security functions behavior FMT_SMF_EXT.1 Specification of Management Functions FPT_ACF_EXT.1 Access controls FPT_ASLR_EXT.1 Address Space Layout Randomization FPT_SBOP_EXT.1 Stack Buffer Overflow Protection FPT_TST_EXT.1 Boot Integrity FPT_TUD_EXT.1 Trusted Update FPT_TUD_EXT.2 Trusted Update for Application Software FTP_ITC_EXT.1 Trusted channel communication Table 23 - Extended Security Functional Components 9.1 Cryptographic Support (FCS) 9.1.1 FCS_CKM_EXT.4 Cryptographic Key Destruction12 FCS_CKM_EXT.4.1 The OS shall destroy cryptographic keys and key material in accordance with a specified cryptographic key destruction method [selection: • For volatile memory, the destruction shall be executed by a [selection: o single overwrite consisting of [selection: a pseudo-random pattern using the TSF's RBG, zeroes, ones, a new value of a key, [assignment: any value that does not contain any CSP]], o removal of power to the memory, o destruction of reference to the key directly followed by a request for garbage collection ], • For non-volatile memory that consists of [selection: o destruction of all key encrypting keys protecting the target key according to FCS_CKM_EXT.4.1, where none of the KEKs protecting the target key are derived 12 TD0365 has been applied. Page 60 of 68 o the invocation of an interface provided by the underlying platform that [selection: ▪ logically addresses the storage location of the key and performs a [selection: single, [assignment: ST author defined multi-pass]] overwrite consisting of [selection: zeroes, ones, pseudo-random pattern, a new value of a key of the same size, [assignment: any value that does not contain any CSP]], ▪ instructs the underlying platform to destroy the abstraction that represents the key] ] ] . FCS_CKM_EXT.4.2 The OS shall destroy all keys and key material when no longer needed. 9.1.2 FCS_RBG_EXT.1 Random Bit Generation FCS_RBG_EXT.1.1 The OS shall perform all deterministic random bit generation (DRBG) services in accordance with NIST Special Publication 800-90A using [selection: • Hash_DRBG (any), • HMAC_DRBG (any), • CTR_DRBG (AES) ] . FCS_RBG_EXT.1.2 The deterministic RBG used by the OS shall be seeded by an entropy source that accumulates entropy from a [selection: • software-based noise source, • platform-based noise source ] with a minimum of [selection: • 128 bits, • 256 bits ] of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate. 9.1.3 FCS_STO_EXT.1 Storage of Sensitive Data FCS_STO_EXT.1 The OS shall implement functionality to encrypt sensitive data stored in non-volatile storage and provide interfaces to applications to invoke this functionality. 9.1.4 FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLS_EXT.1 .1 The product shall implement [ • TLS as a client FCS_TLSC_EXT.1.1 The OS shall implement TLS 1.2 (RFC 5246) supporting the following cipher suites: [selection: • TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246 , • TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 5246, • TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246, Page 61 of 68 • TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246, • TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288, • TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288, • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 , • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 , • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288, • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 , • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289, • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289, • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289, • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289, • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 , • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 , • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 , • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 ]. FCS_TLSC_EXT.1.2 The OS shall verify that the presented identifier matches the reference identifier according to RFC 6125. FCS_TLSC_EXT.1.3 The OS shall only establish a trusted channel if the peer certificate is valid. 9.1.5 FCS_TLSC_EXT.5 TLS Client Support for Supported Groups Extension FCS_TLSC_EXT.5.1 The product shall present the Supported Groups Extension in the Client Hello with the supported groups: [selection: secp384r1, secp521r1]. 9.1.6 FCS_SSH_EXT.1 SSH Protocol FCS_SSH_EXT.1.1 The TOE shall implement SSH acting as a [selection: client, server] in accordance with that complies with RFCs 4251, 4252, 4253, 4254, [selection: 4256, 4344, 5647, 5656, 6187, 6668, 8268, 8308, 8332, 8709, 8731, no other RFCs] and [no other standard]. FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following authentication methods: [selection: “password” (RFC 4252), “keyboard-interactive” (RFC 4256), “publickey” (RFC 4252): [selection: ssh-rsa (RFC 4253), rsa-sha2-256 (RFC 8332), rsa-sha2-512 (RFC 8332), ecdsa-sha2-nistp256 (RFC 5656), ecdsa-sha2-nistp384 (RFC 5656), ecdsa-sha2-nistp521 (RFC 5656), ssh-ed25519 (RFC 8709), ssh-ed448 (RFC 8709), x509v3-ecdsa-sha2-nistp256 (RFC 6187), x509v3- ecdsa-sha2-nistp384 (RFC 6187), x509v3-ecdsa-sha2-nistp521 (RFC 6187), x509v3-rsa2048-sha256 (RFC 6187) ] ] and no other methods. FCS_SSH_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [assignment: number of bytes between 35,000 and 1 GB (inclusive)] in an SSH transport connection are dropped. FCS_SSH_EXT.1.4 The TSF shall protect data in transit from unauthorised disclosure using the following mechanisms: [selection: aes128-ctr (RFC 4344), aes256-ctr (RFC 4344), aes128-cbc (RFC 4253), aes256- Page 62 of 68 cbc (RFC 4253), AEAD_AES_128_GCM (RFC 5647), AEAD_AES_256_GCM (RFC 5647), aes128- gcm@openssh.com (RFC 5647), aes256-gcm@openssh.com (RFC 5647) ] and no other mechanisms. FCS_SSH_EXT.1.5 The TSF shall protect data in transit from modification, deletion, and insertion using: [selection: hmac-sha2-256 (RFC 6668), hmac-sha2-512 (RFC 6668), AEAD_AES_128_GCM (RFC 5647), AEAD_AES_256_GCM (RFC 5647), implicit ] and no other mechanisms. FCS_SSH_EXT.1.6 The TSF shall establish a shared secret with its peer using: [selection: diffie-hellman- group14-sha256 (RFC 8268), diffie-hellman-group15-sha512 (RFC 8268), diffie-hellman-group16-sha512 (RFC 8268), diffie-hellman-group17-sha512 (RFC 8268), diffie-hellman-group18-sha512 (RFC 8268), ecdh-sha2-nistp256 (RFC 5656), ecdh-sha2-nistp384 (RFC 5656), ecdh-sha2-nistp521 (RFC 5656), curve25519-sha256 (RFC 8731), curve448-sha512 (RFC 8731) ] and no other mechanisms. FCS_SSH_EXT.1.7 The TSF shall use SSH KDF as defined in [selection: RFC 4253 (Section 7.2), RFC 5656 (Section 4) ] to derive the following cryptographic keys from a shared secret: session keys. FCS_SSH_EXT.1.8 The TSF shall ensure that [selection: a rekey of the session keys, connection termination ] occurs when any of the following thresholds are met: one hour connection time no more than one gigabyte of transmitted data, or no more than one gigabyte of received data. 9.1.7 FCS_SSHC_EXT.1 SSH Protocol - Client FCS_SSHC_EXT.1.1 The TSF shall authenticate its peer (SSH server) using: [selection: using a local database by associating each host name with a public key corresponding to the following list: [selection: ssh-rsa (RFC 4253), rsa-sha2-256 (RFC 8332), rsa-sha2-512 (RFC 8332), ecdsa-sha2-nistp256 (RFC 5656), ecdsa-sha2-nistp384 (RFC 5656), ecdsa-sha2-nistp521 (RFC 5656), ssh-ed25519 (RFC 8709), ssh-ed448 (RFC 8709) ] , a list of trusted certification authorities when the public key is in the following formats: [selection: x509v3-ecdsa-sha2-nistp256 (RFC 6187), x509v3-ecdsa-sha2-nistp384 (RFC 6187), x509v3- ecdsa-sha2-nistp521 (RFC 6187), x509v3-rsa2048-sha256 (RFC 6187) ] ] as described in RFC 4251 section 4.1. 9.1.8 FCS_SSHS_EXT.1 SSH Protocol - Server FCS_SSHS_EXT.1.1 The TSF shall authenticate itself to its peer (SSH Client) using: [selection: ssh-rsa (RFC 4253), rsa-sha2-256 (RFC 8332), rsa-sha2-512 (RFC 8332), ecdsa-sha2-nistp256 (RFC 5656), ecdsa- sha2-nistp384 (RFC 5656), ecdsa-sha2-nistp521 (RFC 5656), x509v3-ecdsa-sha2-nistp256 (RFC 6187), x509v3-ecdsa-sha2-nistp384 (RFC 6187), x509v3-ecdsa-sha2-nistp521 (RFC 6187), x509v3-rsa2048- sha256 (RFC 6187), ssh-ed25519 (RFC 8709), ssh-ed448 (RFC 8709) ]. 9.2 User Data Protection (FDP) 9.2.1 FDP_IFC_EXT.1 Information flow control FDP_IFC_EXT.1.1 The OS shall [selection: • provide an interface which allows a VPN client to protect all IP traffic using IPsec, Page 63 of 68 • provide a VPN client which can protects all IP traffic using IPsec ] with the exception of IP traffic required to establish the VPN connection and [selection: signed updates directly from the OS vendor, no other traffic]. 9.2.2 FDP_ACF_EXT.1 Access Controls for Protecting User Data FDP_ACF_EXT.1 The OS shall implement access controls which can prohibit unprivileged users from accessing files and directories owned by other users. 9.3 Identification and Authentication (FIA) 9.3.1 FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT.1.1 The OS shall implement functionality to validate certificates in accordance with the following rules: • RFC 5280 certificate validation and certificate path validation • The certificate path must terminate with a trusted CA certificate • The OS shall validate a certificate path by ensuring the presence of the basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and that any path constraints are met. • The TSF shall validate that any CA certificate includes caSigning purpose in the key usage field • The OS shall validate the revocation status of the certificate using [selection: OCSP as specified in RFC 6960, CRL as specified in RFC 8603, an OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066, OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961] with [selection: no exceptions, [assignment: exceptional use cases and alternative status check]] • The OS shall validate the extendedKeyUsage field according to the following rules: o Certificates used for trusted updates and executable code integrity verification shall have the Code Signing Purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field. o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the EKU field. o S/MIME certificates presented for email encryption and signature shall have the Email Protection purpose (id-kp 4 with OID 1.3.6.1.5.5.7.3.4) in the EKU field. o OCSP certificates presented for OCSP responses shall have the OCSP Signing Purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the EKU field. o [selection: Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the EKU field, no other rules]. FIA_X509_EXT.1.2 The OS shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. Page 64 of 68 9.3.2 FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.2.1 The OS shall use X.509v3 certificates as defined by RFC 5280 to support authentication for TLS and [selection: DTLS, HTTPS, [assignment: other protocols], no other protocols] connections. 9.4 Security Management (FMT) 9.4.1 FMT_MOF_EXT.1 Management of security functions behavior FMT_MOF_EXT.1.1 The OS shall restrict the ability to perform the function indicated in the "Administrator" column in FMT_SMF_EXT.1.1 to the administrator. 9.4.2 FMT_SMF_EXT.1 Specification of Management Functions FMT_SMF_EXT.1.1 The OS shall be capable of performing the following management functions: Management Function Administrator User Enable/disable [selection: screen lock, session timeout] M O Configure [selection: screen lock, session] inactivity timeout M O Configure local audit storage capacity O O Configure minimum password length O O Configure minimum number of special characters in password O O Configure minimum number of numeric characters in password O O Configure minimum number of uppercase characters in password O O Configure minimum number of lowercase characters in password O O Configure lockout policy for unsuccessful authentication attempts through [selection: timeouts between attempts, limiting number of attempts during a time period] O O Configure host-based firewall O O Configure name/address of directory server with which to bind O O Configure name/address of remote management server from which to receive management settings O O Configure name/address of audit/logging server to which to send audit/logging records O O Page 65 of 68 Configure audit rules O O Configure name/address of network time server O O Enable/disable automatic software update O O Configure WiFi interface O O Enable/disable Bluetooth interface O O Enable/disable [assignment: list of other external interfaces] O O [assignment: list of other management functions to be provided by the TSF] O O 9.5 Protection of the TSF (FPT) 9.5.1 FPT_ACF_EXT.1 Access controls FPT_ACF_EXT.1.1 The OS shall implement access controls which prohibit unprivileged users from modifying: • Kernel and its drivers/modules • Security audit logs • Shared libraries • System executables • System configuration files • [assignment: other objects]. FPT_ACF_EXT.1.2 The OS shall implement access controls which prohibit unprivileged users from reading: • Security audit logs • System-wide credential repositories • [assignment: list of other objects]. 9.5.2 FPT_ASLR_EXT.1 Address Space Layout Randomization FPT_ASLR_EXT.1.1 The OS shall always randomize process address space memory locations with [selection: 8, [assignment: number greater than 8]] bits of entropy except for [assignment: list of explicit exceptions]. 9.5.3 FPT_SBOP_EXT.1 Stack Buffer Overflow Protection FPT_SBOP_EXT.1.1 The OS shall [selection: employ stack-based buffer overflow protections, not store parameters/variables in the same data structures as control flow values]. Page 66 of 68 9.6 FPT_TST_EXT.1 Boot Integrity FPT_TST_EXT.1.1 The OS shall verify the integrity of the bootchain up through the OS kernel and [selection: • all executable code stored in mutable media, • [assignment: list of other executable code], • no other executable code ] prior to its execution through the use of [selection: • a digital signature using a hardware-protected asymmetric key, • a hardware-protected hash ] . 9.6.1 FPT_TUD_EXT.1 Trusted Update FPT_TUD_EXT.1.1 The OS shall provide the ability to check for updates to the OS software itself. FPT_TUD_EXT.1.2 The OS shall [selection: cryptographically verify, invoke platform-provided functionality to cryptographically verify] updates to itself using a digital signature prior to installation using schemes specified in FCS_COP.1/SIGN.13 9.6.2 FPT_TUD_EXT.2 Trusted Update for Application Software FPT_TUD_EXT.2.1 The OS shall provide the ability to check for updates to application software. FPT_TUD_EXT.2.2 The OS shall [selection: cryptographically verify, invoke platform-provided functionality to cryptographically verify] updates to itself using a digital signature prior to installation using schemes specified in FCS_COP.1/SIGN. 9.7 Trusted Path/Channels (FTP) 9.7.1 FTP_ITC_EXT.1 Trusted channel communication FTP_ITC_EXT.1.1 The OS shall use [selection: • TLS as conforming to FCS_TLSC_EXT.1, • DTLS as conforming to FCS_DTLS_EXT.1, • IPsec as conforming to the PP-Module for VPN Clients, • SSH as conforming to the Function Package for Secure Shell ] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: [selection: audit server, authentication server, management server, 13 TD0386 has been applied. Page 67 of 68 [assignment: other capabilities]] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data. Page 68 of 68 10 Annex C - Extended Security Assurance Components 10.1 Life Cycle (ALC) 10.1.1 ALC_TSU_EXT.1 Timely Security Updates Developer action elements: ALC_TSU_EXT.1.1D The developer shall provide a description in the TSS of how timely security updates are made to the OS. ALC_TSU_EXT.1.2D The developer shall provide a description in the TSS of how users are notified when updates change security properties or the configuration of the product. Content and presentation elements: ALC_TSU_EXT.1.1C The description shall include the process for creating and deploying security updates for the OS software. ALC_TSU_EXT.1.2C The description shall include the mechanisms publicly available for reporting security issues pertaining to the OS. Note: The reporting mechanism could include web sites, email addresses, as well as a means to protect the sensitive nature of the report (e.g., public keys that could be used to encrypt the details of a proof- of-concept exploit).