SUSE Linux Enterprise Server 11 SP2 on IBM System z 1.3 Version: Released Status: 2013-02-19 Last Update: SUSE and atsec public Classification: Trademarks SUSE and the SUSE logo are trademarks or registered trademarks of SUSE Linux Products GmbH in Germany, other countries, or both. atsec is a trademark of atsec information security GmbH Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group in the United States and other countries. IBM, IBM logo, bladecenter, eServer, iSeries, OS/400, , POWER3, POWER4, POWER4+, pSeries, System p, POWER5, POWER5+, POWER6, POWER6+, POWER7, POWER7+, System x, System z, S390, xSeries, zSeries, zArchitecture, and z/VM are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Intel, Xeon, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. This document is based in parts on the Red Hat Enterprise Linux Version 5.1 Security Target, Copyright © 2010 by Red Hat, Inc. and atsec information security corp. 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. Revision History Changes to Previous Revision Author(s) Date Revision Release first version Stephan Mueller 2012-09-28 1.0 Update FCS_RNG.1 based on BSI comments Stephan Mueller 2013-01-17 1.1 Remove spurious traces of AppArmor support for KVM Stephan Mueller 2013-02-13 1.2 Update list of underlying systems Stephan Mueller 2013-02-19 1.3 Page 2 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Table of Contents 1 Introduction ................................................................................................. 8 1.1 Security Target Identification ..................................................................................... 8 1.2 TOE Identification ...................................................................................................... 8 1.3 TOE Type ................................................................................................................... 8 1.4 TOE Overview ............................................................................................................ 8 1.4.1 Configurations defined with this ST .................................................................. 8 1.4.2 Overview description ........................................................................................ 8 1.4.3 Required Hardware and Software ..................................................................... 8 1.4.4 Intended Method of Use ................................................................................... 8 1.4.4.1 General-purpose computing environment ............................................... 8 1.4.4.2 Operating environment ............................................................................ 9 1.4.5 Major Security Features .................................................................................... 9 1.5 TOE Description ......................................................................................................... 9 1.5.1 Introduction ...................................................................................................... 9 1.5.2 TOE boundaries .............................................................................................. 10 1.5.2.1 Physical .................................................................................................. 10 1.5.2.2 Logical .................................................................................................... 10 1.5.2.3 Configurations ........................................................................................ 12 1.5.2.4 TOE Environment ................................................................................... 13 1.5.2.5 Security Policy Model ............................................................................. 13 2 CC Conformance Claim ................................................................................ 15 3 Security Problem Definition ........................................................................ 16 3.1 Threat Environment ................................................................................................. 16 3.1.1 Assets ............................................................................................................. 16 3.1.2 Threat Agents ................................................................................................. 16 3.1.3 Threats countered by the TOE ........................................................................ 16 3.2 Assumptions ............................................................................................................ 17 3.2.1 Environment of use of the TOE ....................................................................... 17 3.2.1.1 Physical .................................................................................................. 17 3.2.1.2 Personnel ............................................................................................... 17 3.2.1.3 Procedural .............................................................................................. 18 3.2.1.4 Connectivity ........................................................................................... 18 3.3 Organizational Security Policies .............................................................................. 18 4 Security Objectives .................................................................................... 20 4.1 Objectives for the TOE ............................................................................................ 20 4.2 Objectives for the Operational Environment ........................................................... 21 4.3 Security Objectives Rationale .................................................................................. 22 4.3.1 Coverage ........................................................................................................ 22 4.3.2 Sufficiency ...................................................................................................... 23 5 Extended Components Definition ................................................................ 28 5.1 Class FDP: User data protection .............................................................................. 28 5.1.1 Confidentiality protection (FDP_CDP) ............................................................. 28 5.1.1.1 FDP_CDP.1 - Confidentiality for data at rest ........................................... 28 5.2 Class FCS: Cryptographic support ........................................................................... 29 5.2.1 Random number generator (RNG) .................................................................. 29 Page 3 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 5.2.1.1 FCS_RNG.1 - Random number generation ............................................. 29 6 Security Requirements ............................................................................... 31 6.1 TOE Security Functional Requirements ................................................................... 31 6.1.1 General-purpose computing environment ...................................................... 34 6.1.1.1 Audit data generation (FAU_GEN.1) ...................................................... 34 6.1.1.2 User identity association (FAU_GEN.2) .................................................. 35 6.1.1.3 Audit review (FAU_SAR.1) ...................................................................... 35 6.1.1.4 Restricted audit review (FAU_SAR.2) ..................................................... 35 6.1.1.5 Selective audit (FAU_SEL.1) .................................................................. 35 6.1.1.6 Protected audit trail storage (FAU_STG.1) ............................................. 36 6.1.1.7 Action in case of possible audit data loss (FAU_STG.3) ......................... 36 6.1.1.8 Prevention of audit data loss (FAU_STG.4) ............................................ 36 6.1.1.9 Cryptographic key generation (FCS_CKM.1(SYM)) ................................ 37 6.1.1.10 Cryptographic key generation (FCS_CKM.1(RSA)) ............................... 37 6.1.1.11 Cryptographic key generation (FCS_CKM.1(DSA)) .............................. 37 6.1.1.12 Cryptographic key distribution (FCS_CKM.2(NET)) .............................. 38 6.1.1.13 Cryptographic key destruction (FCS_CKM.4) ....................................... 38 6.1.1.14 Cryptographic operation (FCS_COP.1(NET)) ........................................ 38 6.1.1.15 Cryptographic operation (FCS_COP.1(CP)) .......................................... 39 6.1.1.16 Random number generation (Class DRG.2) (FCS_RNG.1(SSH-DFLT)) ............................................................................................................................. 39 6.1.1.17 Random number generation (Class DRG.2) (FCS_RNG.1(SSH-FIPS)) ............................................................................................................................. 39 6.1.1.18 Random number generation (Class DRG.2) (FCS_RNG.1(DM)) ............ 40 6.1.1.19 Subset access control (FDP_ACC.1(PSO)) ............................................ 40 6.1.1.20 Subset access control (FDP_ACC.1(TSO)) ............................................ 41 6.1.1.21 Security attribute based access control (FDP_ACF.1(PSO)) ................. 41 6.1.1.22 Security attribute based access control (FDP_ACF.1(TSO)) ................. 43 6.1.1.23 Complete information flow control (FDP_IFC.2(NI)) ............................. 44 6.1.1.24 Simple security attributes (FDP_IFF.1(NI-IPTables)) ............................. 44 6.1.1.25 Simple security attributes (FDP_IFF.1(NI-ebtables)) ............................ 45 6.1.1.26 Import of user data with security attributes (FDP_ITC.2(BA)) .............. 46 6.1.1.27 Full residual information protection (FDP_RIP.2) .................................. 46 6.1.1.28 Full residual information protection of resources (FDP_RIP.3) ............. 46 6.1.1.29 Authentication failure handling (FIA_AFL.1) ........................................ 46 6.1.1.30 User attribute definition (FIA_ATD.1(HU)) ........................................... 47 6.1.1.31 User attribute definition (FIA_ATD.1(TU)) ............................................ 47 6.1.1.32 Verification of secrets (FIA_SOS.1) ...................................................... 47 6.1.1.33 Timing of authentication (FIA_UAU.1) ................................................. 48 6.1.1.34 Multiple authentication mechanisms (FIA_UAU.5) ............................... 48 6.1.1.35 Protected authentication feedback (FIA_UAU.7) ................................. 48 6.1.1.36 Timing of identification (FIA_UID.1) ..................................................... 48 6.1.1.37 Enhanced user-subject binding (FIA_USB.2) ........................................ 49 6.1.1.38 Reliable time stamps (FPT_STM.1) ...................................................... 50 6.1.1.39 Inter-TSF basic TSF data consistency (FPT_TDC.1(BA)) ....................... 50 6.1.1.40 TSF-initiated session locking (FTA_SSL.1) ........................................... 51 6.1.1.41 User-initiated locking (FTA_SSL.2) ....................................................... 51 6.1.1.42 Inter-TSF trusted channel (FTP_ITC.1) ................................................. 51 6.1.2 Confidentiality protection of data at rest ........................................................ 52 Page 4 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 6.1.2.1 Complete access control (FDP_ACC.2(CP)) ............................................ 52 6.1.2.2 Security attribute based access control (FDP_ACF.1(CP)) ..................... 52 6.1.2.3 Confidentiality for data at rest (FDP_CDP.1(CP)) ................................... 53 6.1.3 Management related functionality .................................................................. 53 6.1.3.1 Management of object security attributes (FMT_MSA.1(PSO)) .............. 53 6.1.3.2 Management of object security attributes (FMT_MSA.1(TSO)) .............. 53 6.1.3.3 Management of security attributes (FMT_MSA.1(CP)) ........................... 53 6.1.3.4 Static attribute initialisation (FMT_MSA.3(PSO)) ................................... 53 6.1.3.5 Static attribute initialisation (FMT_MSA.3(TSO)) ................................... 54 6.1.3.6 Static attribute initialisation (FMT_MSA.3(NI)) ....................................... 54 6.1.3.7 Static attribute initialisation (FMT_MSA.3(CP)) ...................................... 54 6.1.3.8 Security attribute value inheritance (FMT_MSA.4(PSO)) ....................... 55 6.1.3.9 Management of TSF data (FMT_MTD.1(AE)) .......................................... 55 6.1.3.10 Management of TSF data (FMT_MTD.1(AS)) ........................................ 55 6.1.3.11 Management of TSF data (FMT_MTD.1(AT)) ........................................ 55 6.1.3.12 Management of TSF data (FMT_MTD.1(AF)) ........................................ 56 6.1.3.13 Management of TSF data (FMT_MTD.1(NI)) ......................................... 56 6.1.3.14 Management of TSF data (FMT_MTD.1(IAT)) ....................................... 56 6.1.3.15 Management of TSF data (FMT_MTD.1(IAF)) ....................................... 56 6.1.3.16 Management of TSF data (FMT_MTD.1(IAU)) ...................................... 56 6.1.3.17 Management of TSF data (FMT_MTD.1(SSH)) ...................................... 57 6.1.3.18 Management of TSF data (FMT_MTD.1(SSL)) ...................................... 57 6.1.3.19 Management of TSF data (FMT_MTD.1(CP-AN)) .................................. 57 6.1.3.20 Management of TSF data (FMT_MTD.1(CP-UD)) .................................. 57 6.1.3.21 Revocation (FMT_REV.1(OBJ)) .............................................................. 57 6.1.3.22 Revocation (FMT_REV.1(USR)) ............................................................. 58 6.1.3.23 Specification of management functions (FMT_SMF.1) ......................... 58 6.1.3.24 Security management roles (FMT_SMR.1) ........................................... 58 6.2 Security Functional Requirements Rationale ........................................................... 59 6.2.1 Coverage ........................................................................................................ 59 6.2.2 Sufficiency ...................................................................................................... 61 6.2.3 Security requirements dependency analysis .................................................. 64 6.3 Security Assurance Requirements ........................................................................... 68 6.3.1 Security Target evaluation (ASE) .................................................................... 69 6.3.1.1 Conformance claims (ASE_CCL.1) ......................................................... 69 6.4 Security Assurance Requirements Rationale ........................................................... 70 7 TOE Summary Specification ........................................................................ 71 7.1 TOE Security Functionality ...................................................................................... 71 7.1.1 Audit ............................................................................................................... 71 7.1.1.1 Audit functionality .................................................................................. 71 7.1.1.2 Audit trail ............................................................................................... 72 7.1.2 Cryptographic services ................................................................................... 72 7.1.2.1 SSHv2 Protocol ....................................................................................... 73 7.1.3 Packet filter ..................................................................................................... 74 7.1.3.1 Network layer filtering ........................................................................... 74 7.1.3.2 Link layer filtering .................................................................................. 76 7.1.4 Identification and Authentication .................................................................... 77 7.1.4.1 PAM-based identification and authentication mechanisms .................... 77 Page 5 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 7.1.4.2 User Identity Changing .......................................................................... 77 7.1.4.3 Authentication Data Management ......................................................... 78 7.1.4.4 SSH key-based authentication ............................................................... 79 7.1.4.5 Session locking ...................................................................................... 79 7.1.5 Discretionary Access Control .......................................................................... 80 7.1.5.1 Permission bits ....................................................................................... 80 7.1.5.2 Access Control Lists (ACLs) .................................................................... 81 7.1.5.3 File system objects ................................................................................. 81 7.1.5.4 IPC objects ............................................................................................. 81 7.1.5.5 at and cron jobs queues ......................................................................... 82 7.1.6 Confidentiality protected data storage ........................................................... 82 7.1.7 Security Management ..................................................................................... 83 7.1.7.1 Privileges ............................................................................................... 83 8 Abbreviations, Terminology and References ................................................ 85 8.1 Abbreviations .......................................................................................................... 85 8.2 Terminology ............................................................................................................. 85 8.3 References .............................................................................................................. 87 Page 6 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z List of Tables Table 1: Non-evaluated functionalities ............................................................................. 11 Table 2: Mapping of security objectives to threats and policies ....................................... 22 Table 3: Mapping of security objectives for the Operational Environment to assumptions, threats and policies ................................................................................................... 23 Table 4: Sufficiency of objectives countering threats ....................................................... 23 Table 5: Sufficiency of objectives holding assumptions ................................................... 25 Table 6: Sufficiency of objectives enforcing Organizational Security Policies ................... 27 Table 7: Security functional requirements for the TOE ..................................................... 31 Table 8: Mapping of security functional requirements to security objectives ................... 59 Table 9: Security objectives for the TOE rationale ........................................................... 62 Table 10: TOE SFR dependency analysis .......................................................................... 64 Table 11: Security assurance requirements ..................................................................... 68 Table 12: SSH implementation notes ............................................................................... 73 Page 7 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 1 Introduction 1.1 Security Target Identification SUSE Linux Enterprise Server 11 SP2 on IBM System z Title: 1.3 Version: Released Status: 2013-02-19 Date: SUSE Linux Products GmbH Sponsor: SUSE Linux Products GmbH Developer: BSI-DSZ-CC-0852 Certification ID: Security Target, Common Criteria, Linux Distribution Keywords: 1.2 TOE Identification The TOE is SUSE Linux Enterprise Version 11 SP2. 1.3 TOE Type The TOE type is Linux-based general-purpose operating system. 1.4 TOE Overview 1.4.1 Configurations defined with this ST This security target documents the security characteristics of the SUSE Linux Enterprise Server distribution (abbreviated with SLES throughout this document). 1.4.2 Overview description SUSE Linux Enterprise Server is a highly-configurable Linux-based operating system which has been developed to provide a good level of security as required in commercial environments. It also meets all requirements of the Operating System Protection Profile [OSPP]. 1.4.3 Required Hardware and Software The following hardware / firmware allows the installation of the TOE: ● IBM: ❍ IBM System z based on z/Architecture version 10 processors 1.4.4 Intended Method of Use 1.4.4.1 General-purpose computing environment The TOE is a Linux-based multi-user multi-tasking operating system. The TOE may provide services to several users at the same time. After successful login, the users have access to a general computing environment, allowing the start-up of user applications, issuing user commands at shell level, creating and accessing files. The TOE provides adequate mechanisms to separate the users and protect their data. Privileged commands are restricted to administrative users. Page 8 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z The TOE is intended to operate in a networked environment with other instantiations of the TOE as well as other well-behaved peer systems operating within the same management domain. All those systems need to be configured in accordance with a defined common security policy. It is assumed that responsibility for the safeguarding of the user data protected by the TOE can be delegated to human users of the TOE if such users are allowed to log on and spawn processes on their behalf. All user data is under the control of the TOE. The user data is stored in named objects, and the TOE can associate a description of the access rights to that object with each named object. The TOE enforces controls such that access to data objects can only take place in accordance with the access restrictions placed on that object by its owner, and by administrative users. Ownership of named objects may be transferred under the control of the access control policies implemented by the TOE. Discretionary access rights (e.g. read, write, execute) can be assigned to data objects with respect to subjects identified with their UID, GID and supplemental GIDs. Once a subject is granted access to an object, the content of that object may be used freely to influence other objects accessible to this subject. 1.4.4.2 Operating environment The TOE permits one or more processors and attached peripheral and storage devices to be used by multiple applications assigned to different UIDs to perform a variety of functions requiring controlled shared access to the data stored on the system. With different UIDs proper access restrictions to resources assigned to processes can be enforced using the access control mechanisms provided by the TOE. Such installations and usage scenarios are typical for systems accessed by processes or users local to, or with otherwise protected access to, the computer system. Note: The TOE provides the platform for installing and running arbitrary services. These additional services are not part of the TOE. The TOE is solely the operating system which provides the runtime environment for such services. All human users, if existent, as well as all services offered by SLES are assigned unique user identifiers within the single host system that forms the TOE. This user identifier is used together with the attributes assigned to the user identifier as the basis for access control decisions. The TOE authenticates the claimed identity of the user before allowing the user to perform any further actions. Services may be spawned by the TOE without the need for user-interaction. The TOE internally maintains a set of identifiers associated with processes, which are derived from the unique user identifier upon login of the user or from the configured user identifier for a TOE-spawned service. Some of those identifiers may change during the execution of the process according to a policy implemented by the TOE. 1.4.5 Major Security Features The primary security features of the TOE are specified as part of the logical boundary description. These primary security features are supported by domain separation and reference mediation, which ensure that the features are always invoked and cannot be bypassed. 1.5 TOE Description 1.5.1 Introduction SLES is a general purpose, multi-user, multi-tasking Linux based operating system. It provides a platform for a variety of applications. Page 9 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z The SLES evaluation covers a potentially distributed network of systems running the evaluated versions and configurations of SLES as well as other peer systems operating within the same management domain. The hardware platforms selected for the evaluation consist of machines which are available when the evaluation has completed and to remain available for a substantial period of time afterwards. The TOE Security Functions (TSF) consist of functions of SLES that run in kernel mode plus a set of trusted processes. These are the functions that enforce the security policy as defined in this Security Target. Tools and commands executed in user mode that are used by an administrative user need also to be trusted to manage the system in a secure way. But as with other operating system evaluations they are not considered to be part of this TSF. The hardware, the BIOS firmware and potentially other firmware layers between the hardware and the TOE are considered to be part of the TOE environment. The TOE includes standard networking applications, such as SSH. System administration tools include the standard command line tools. A graphical user interface for system administration or any other operation is not included in the evaluated configuration. The TOE environment also includes applications that are not evaluated, but are used as unprivileged tools to access public system services. For example a network server using a port above 1024 may be used as a normal application running without root privileges on top of the TOE. The additional documentation specific for the evaluated configuration provides guidance how to set up such applications on the TOE in a secure way. 1.5.2 TOE boundaries 1.5.2.1 Physical The Target of Evaluation is based on the following system software: ● SUSE Linux Enterprise Server in the above mentioned version The TOE and its documentation are supplied on ISO images distributed via the SUSE Portal. The TOE includes a package holding the additional user and administrator documentation. In addition to the installation media, the following documentation is provided: ● Evaluated Configuration Guide ● Manual pages for all applications, configuration files and system calls The hardware applicable to the evaluated configuration is listed above. The analysis of the hardware capabilities as well as the firmware functionality is covered by this evaluation to the extent that the following capabilities supporting the security functionality are analyzed and tested: ● Memory separation capability ● Unavailability of privileged processor states to untrusted user code (like the hypervisor state or the SMM) ● Full testing of the security functionality on all listed hardware systems 1.5.2.2 Logical The primary security features of the TOE are: ● Auditing: The Lightweight Audit Framework (LAF) is designed to be an audit system making Linux compliant with the requirements from Common Criteria. LAF is able to intercept all system calls as well as retrieving audit log entries from privileged user space applications. The subsystem allows configuring the events to be actually audited from the set of all events that are possible to be audited. Page 10 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z ● Cryptographic support: The TOE provides cryptographically secured communication channels as well as cryptographic primitives that unprivileged users can utilize for unspecified purposes. The TOE provides cryptographically secured communication to allow remote entities to log into the TOE. For interactive usage, the SSHv2 protocol is provided. ● Packet filter: The TOE provides a stateless and stateful packet filter for regular IP-based communication. Layer 3 (IP) and layer 4 (TCP, UDP, ICMP) network protocols can be controlled using this packet filter. The TOE provides a bridging functionality. Ethernet frames routed through bridges are controlled by a separate packet filter which implements a stateless packet filter for the TCP/IP protocol family. ● Identification and Authentication: User identification and authentication in the TOE includes all forms of interactive login (e.g. using the SSH protocol or log in at the local console) as well as identity changes through the su or sudo command. These all rely on explicit authentication information provided interactively by a user. ● Discretionary Access Control: DAC allows owners of named objects to control the access permissions to these objects. These owners can permit or deny access for other users based on the configured permission settings. The DAC mechanism is also used to ensure that untrusted users cannot tamper with the TOE mechanisms. ● Confidentiality protected data storage: Using dm_crypt, the Linux operating system offers administrators and users cryptographically protected storage space. Only with the passphrase can the session key used for encryption or decryption be obtained and used. Any data stored on the devices protected by dm_crypt is encrypted and cannot be accessed even when the TOE is not operational. An operational TOE is needed to unlock the device session key. ● Security Management: The security management facilities provided by the TOE are usable by authorized users and/or authorized administrators to modify the configuration of TSF. The TOE provides many more functions and mechanisms. The evaluation ensures that all these additional functions do not interfere with the above mentioned security mechanisms in the evaluated configuration. Mechanisms and functions that would interfere with the operation of the security functions are disallowed in the evaluated configuration and the Evaluation Configuration Guide provides instructions to the administrator on how to disable them. Note: TOE mechanism which provide additional restrictions to the above claimed security functions are allowed in the evaluated configuration. For example, Linux Containers are provided with the TOE and permitted in the evaluated configuration even though they have not been subject to this evaluation. Linux Containers provide futher restrictions on, for example, the security function of discretionary access control mechanism for IPC objects and therefore cannot breach the security functionality. The following table enumerates mechanisms that are provided with the TOE but which are excluded from the evaluation: Exclusion discussion Functions eCryptFS are not allowed to be used in the evaluated configuration. The encryption capability provided with this file system is therefore unavailable to any user. eCryptFS The mandatory access control functionality offered by the SMACK LSM is not assessed by the evaluation and disabled in the evaluated configuration. SMACK The mandatory access control functionality offered by the SELinux LSM is not assessed by the evaluation and disabled in the evaluated configuration. SELinux Page 11 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Exclusion discussion Functions The TOE provides the stunnel application which can be used to establish SSL and TLS tunnels with remote peers. This application however was excluded from evaluation assessment. SSL / TLS tunnels As mentioned above, the BSDJails are not assessed in this evaluation. BSDJails As mentioned above, the Linux Containers are not subject to assessment in this evaluation. Linux Containers The GSS-API is used to secure the connection between different audit daemons. The security mechanisms used by the GSS-API, however, is not part of the evaluation. Therefore, A.CONNECT applies to the audit-related communication link. GSS-API Security Mechanisms Table 1: Non-evaluated functionalities Note: Packages and mechanisms not covered with security claims and subsequent assessments during the evaluation or disabling the respective functionality in the evaluated configuration result from resource constraints during the evaluation but does not imply that the respective package or functionality is implemented insecurely. 1.5.2.3 Configurations The evaluated configurations are defined as follows: ● The CC evaluated package set must be selected at install time in accordance with the description provided in the Evaluated Configuration Guide and installed accordingly. ● The TOE supports the use of IPv4 and IPv6, both are also supported in the evaluated configuration. IPv6 conforms to the following RFCs: ❍ RFC 2460 specifying the basic IPv6 protocol ❍ IPv6 source address selection as documented in RFC 3484 ❍ Linux implements several new socket options (IPV6_RECVPKTINFO, IPV6_PKTINFO, IPV6_RECVHOPOPTS, IPV6_HOPOPTS, IPV6_RECVDSTOPTS, IPV6_DSTOPTS, IPV6_RTHDRDSTOPTS, IPV6_RECVRTHDR, IPV6_RTHDR, IPV6_RECVHOPOPTS, IPV6_HOPOPTS, IPV6_{RECV,}TCLASS) and ancillary data in order to support advanced IPv6 applications including ping, traceroute, routing daemons and others. The following section introduces Internet Protocol Version 6 (IPv6). For additional information about referenced socket options and advanced IPv6 applications, see RFC 3542 ❍ Transition from IPv4 to IPv6: dual stack, and configured tunneling according to RFC 4213. ● The default configuration for identification and authentication are the defined password-based PAM modules as well as certificate based authentication for OpenSSH. Support for other authentication options, e.g. smart card authentication, is not included in the evaluation configuration. ● If the system console is used, it must be connected directly to the TOE and afforded the same physical protection as the TOE. Deviations from the configurations and settings specified with the Evaluated Configuration Guide are not permitted. The TOE comprises a single system (and optional peripherals) running the TOE software listed. Cluster configurations are not permitted in the evaluated configuration. Page 12 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 1.5.2.4 TOE Environment Several TOE systems may be interlinked in a network, and individual networks may be joined by bridges and/or routers, or by TOE systems which act as routers and/or gateways. Each of the TOE systems implements its own security policy. The TOE does not include any synchronization function for those policies. As a result a single user may have user accounts on each of those systems with different UIDs, different roles, and other different attributes. (A synchronization method may optionally be used, but it not part of the TOE and must not use methods that conflict with the TOE requirements.) If other systems are connected to a network they need to be configured and managed by the same authority using an appropriate security policy that does not conflict with the security policy of the TOE. All links between this network and untrusted networks (e. g. the Internet) need to be protected by appropriate measures such as carefully configured firewall systems that prohibit attacks from the untrusted networks. Those protections are part of the TOE environment. 1.5.2.5 Security Policy Model The security policy for the TOE is defined by the security functional requirements in chapter 6. The following is a list of the subjects and objects participating in the policy. Subjects: ● Processes acting on behalf of a human user or technical entity. Named objects: ● File system objects in the following allowed file systems: ❍ btrfs - standard file system for general data ❍ ext3 - standard file system for general data ❍ xfs - standard file system for general data ❍ vfat - special purpose file system for UEFI BIOS support mounted at /boot/efi ❍ iso9660 - ISO9660 file system for CD-ROM and DVD ❍ tmpfs - the temporary file system backed by RAM ❍ rootfs - the virtual root file system used temporarily during system boot ❍ procfs - process file system holding information about processes, general statistical data and tunable kernel parameters ❍ sysfs - system-related file system covering general information about resources maintained by the kernel including several tunable parameters for these resources ❍ devpts - pseudoterminal file system for allocating virtual TTYs on demand ❍ devtmpfs - temporary file system that allows the kernel to generate character or block device nodes ❍ binfmt_misc - configuration interface allowing the assignment of executable file formats with user space applications ❍ cgroup - interface for configuring the control groups mechanism provided by the kernel ❍ debugfs - interface for accessing low-level kernel data Please note that the TOE supports a number of additional virtual (i.e. without backing of persistent storage) file systems which are only accessible to the TSF - they are not or cannot be mounted. All above mentioned virtual file systems implement access decisions based DAC attributes inferred from the underlying process’ DAC attributes. Additional restrictions may apply for specific objects in this file system. ● Inter Process Communication (IPC) objects: ❍ Semaphores Page 13 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z ❍ Shared memory ❍ Message queues ❍ Named pipes ❍ UNIX domain socket special files ● Network sockets (irrespectively of their type - such as Internet sockets and netlink sockets) ● Storage device objects (covered by dm_crypt - note that such storage device objects may be provided by either block devices or LVM devices) ● at and cron job queues maintained for each user TSF data: ● TSF executable code ● Subject meta data - all data used for subjects except data which is not interpreted by the TSF and does not implement parts of the TSF (this data is called user data) ● Named object meta data - all data used for the respective objects except data which is not interpreted by the TSF and does not implement parts of the TSF (this data is called user data) ● User accounts, including the security attributes defined by FIA_ATD.1 ● Audit records ● Session keys for dm_crypt block devices and passphrases protecting the session keys User data: ● Non-TSF executable code used to drive the behavior of subjects ● Data not interpreted by TSF and stored or transmitted using named objects Page 14 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 2 CC Conformance Claim This ST is CC Part 2 extended and CC Part 3 conformant, with a claimed Evaluation Assurance Level of EAL4, augmented by ALC_FLR.3. This ST claims conformance to the following Protection Profiles: ● [OSPP]: BSI Operating System Protection Profile. Version 2.0 as of 2010; strict conformance. Common Criteria [CC] version 3.1 revision 3 is the basis for this conformance claim. Page 15 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 3 Security Problem Definition 3.1 Threat Environment Threats to be countered by the TOE are characterized by the combination of an asset being subject to a threat, a threat agent and an adverse action. The definition of threat agents and protected assets that follows is applicable to the OSPP base, as well as to the OSPP extended packages, unless noted otherwise. 3.1.1 Assets Assets to be protected are: ● Persistent storage objects used to store user data and/or TSF data, where this data needs to be protected from any of the following operations: ❍ Unauthorized read access ❍ Unauthorized modification ❍ Unauthorized deletion of the object ❍ Unauthorized creation of new objects ❍ Unauthorized management of object attributes ● Transient storage objects, including network data ● TSF functions and associated TSF data ● The resources managed by the TSF that are used to store the above-mentioned objects, including the metadata needed to manage these objects. 3.1.2 Threat Agents Threat agents are external entities that potentially may attack the TOE. They satisfy one or more of the following criteria: ● External entities not authorized to access assets may attempt to access them either by masquerading as an authorized entity or by attempting to use TSF services without proper authorization. ● External entities authorized to access certain assets may attempt to access other assets they are not authorized to either by misusing services they are allowed to use or by masquerading as a different external entity. ● Untrusted subjects may attempt to access assets they are not authorized to either by misusing services they are allowed to use or by masquerading as a different subject. Threat agents are typically characterized by a number of factors, such as expertise, available resources, and motivation, with motivation being linked directly to the value of the assets at stake. The TOE protects against intentional and unintentional breach of TOE security by attackers possessing an enhanced-basic attack potential. 3.1.3 Threats countered by the TOE T.ACCESS.TSFDATA A threat agent might read or modify TSF data without the necessary authorization when the data is stored or transmitted. T.ACCESS.USERDATA A threat agent might gain access to user data stored, processed or transmitted by the TOE without being appropriately authorized according to the TOE security policy. Page 16 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z T.ACCESS.TSFFUNC A threat agent might use or modify functionality of the TSF without the necessary privilege to grant itself or others unauthorized access to TSF data or user data. T.ACCESS.COMM A threat agent might access a communication channel that establishes a trust relationship between the TOE and another remote trusted IT system or masquerade as another remote trusted IT system. T.RESTRICT.NETTRAFFIC A threat agent might get access to information or transmit information to other recipients via network communication channels without authorization for this communication attempt by the information flow control policy. T.IA.MASQUERADE A threat agent might masquerade as an authorized entity including the TOE itself or a part of the TOE in order to gain unauthorized access to user data, TSF data, or TOE resources. T.IA.USER A threat agent might gain access to user data, TSF data or TOE resources with the exception of public objects without being identified and authenticated. T.ACCESS.CP.USERDATA A threat agent might gain access to user data at rest which is confidentiality protected without possessing the authorization of the owner, either at runtime of the TOE or when the TSF are inactive. 3.2 Assumptions 3.2.1 Environment of use of the TOE 3.2.1.1 Physical A.PHYSICAL It is assumed that the IT environment provides the TOE with appropriate physical security, commensurate with the value of the IT assets protected by the TOE. 3.2.1.2 Personnel A.MANAGE The TOE security functionality is managed by one or more competent individuals. The system administrative personnel are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the guidance documentation. A.AUTHUSER Authorized users possess the necessary authorization to access at least some of the information managed by the TOE and are expected to act in a cooperating manner in a benign environment. Page 17 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z A.TRAINEDUSER Users are sufficiently trained and trusted to accomplish some task or group of tasks within a secure IT environment by exercising complete control over their user data. 3.2.1.3 Procedural A.DETECT Any modification or corruption of security-enforcing or security-relevant files of the TOE, user or the underlying platform caused either intentionally or accidentally will be detected by an administrative user. A.PEER.MGT All remote trusted IT systems trusted by the TSF to provide TSF data or services to the TOE, or to support the TSF in the enforcement of security policy decisions are assumed to be under the same management control and operate under security policy constraints compatible with those of the TOE. A.PEER.FUNC All remote trusted IT systems trusted by the TSF to provide TSF data or services to the TOE, or to support the TSF in the enforcement of security policy decisions are assumed to correctly implement the functionality used by the TSF consistent with the assumptions defined for this functionality. 3.2.1.4 Connectivity A.CONNECT All connections to and from remote trusted IT systems and between physically-separate parts of the TSF not protected by the TSF itself are physically or logically protected within the TOE environment to ensure the integrity and confidentiality of the data transmitted and to ensure the authenticity of the communication end points. 3.3 Organizational Security Policies P.ACCOUNTABILITY The users of the TOE shall be held accountable for their security-relevant actions within the TOE. P.USER Authority shall only be given to users who are trusted to perform the actions correctly. P.PROTECT_SSH_KEY When using SSH with key-based authentication, organizational procedures must exist that ensure users protect their private SSH key component against its use by any other user. Note: The protection of the key can be established by access permissions to the file holding the key (when using the OpenSSH client, the key file permissions are automatically verified and the key is rejected if the permissions are not restrictive), or by encrypting the key with a passphrase. Making the SSH private key available to any other user is akin to telling that user the password for password-based authentication. Page 18 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z P.CP.ANCHOR Users shall control the confidentiality protection anchor for their confidentiality-protected user data, and reset/replace/modify it if desired. Page 19 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 4 Security Objectives 4.1 Objectives for the TOE O.AUDITING The TSF must be able to record defined security-relevant events (which usually include security-critical actions of users of the TOE). The TSF must protect this information and present it to authorized users if the audit trail is stored on the local system. The information recorded for security-relevant events must contain the time and date the event happened and, if possible, the identification of the user that caused the event, and must be in sufficient detail to help the authorized user detect attempted security violations or potential misconfiguration of the TOE security features that would leave the IT assets open to compromise. O.CRYPTO.NET The TSF must allow authorized users to remotely access the TOE using a cryptographically-protected network protocol that ensures integrity and confidentiality of the transported data and is able to authenticate the end points of the communication. Note that the same protocols may also be used in the case where the TSF is physically separated into multiple parts that must communicate securely with each other over untrusted network connections. O.DISCRETIONARY.ACCESS The TSF must control access of subjects and/or users to named resources based on identity of the object. The TSF must allow authorized users to specify for each access mode which users/subjects are allowed to access a specific named object in that access mode. O.NETWORK.FLOW The TOE shall mediate communication between sets of TOE network interfaces, between a network interface and the TOE itself, and between subjects in the TOE and the TOE itself in accordance with its security policy. O.SUBJECT.COM The TOE shall mediate communication between subjects acting with different subject security attributes in accordance with its security policy. O.I&A The TOE must ensure that users have been successfully authenticated before allowing any action the TOE has defined to provide to authenticated users only. O.MANAGE The TSF must provide all the functions and facilities necessary to support the authorized users that are responsible for the management of TOE security mechanisms and must ensure that only authorized users are able to access such functionality. O.TRUSTED_CHANNEL The TSF must be designed and implemented in a manner that allows for establishing a trusted channel between the TOE and a remote trusted IT system that protects the user data and TSF data transferred over this channel from disclosure and undetected modification and prevents masquerading of the remote trusted IT system. Page 20 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z O.CP.USERDATA The TOE shall be able to protect the confidentiality of user data at rest separately for each user where the user can select the data which is being maintained under confidentiality protection. O.CP.ANCHOR The TOE shall allow each user to manage the trust anchor for the confidentiality protection of his own user data. 4.2 Objectives for the Operational Environment OE.ADMIN Those responsible for the TOE are competent and trustworthy individuals, capable of managing the TOE and the security of the information it contains. OE.REMOTE If the TOE relies on remote trusted IT systems to support the enforcement of its policy, those systems provide the functions required by the TOE and are sufficiently protected from any attack that may cause those functions to provide false results. OE.INFO_PROTECT Those responsible for the TOE must establish and implement procedures to ensure that information is protected in an appropriate manner. In particular: ● All network and peripheral cabling must be approved for the transmittal of the most sensitive data held by the system. Such physical links are assumed to be adequately protected against threats to the confidentiality and integrity of the data transmitted. ● DAC protections on security-relevant files (such as audit trails and authentication databases) shall always be set up correctly. ● Users are authorized to access parts of the data managed by the TOE and are trained to exercise control over their own data. OE.INSTALL Those responsible for the TOE must establish and implement procedures to ensure that the hardware, software and firmware components that comprise the system are distributed, installed and configured in a secure manner supporting the security mechanisms provided by the TOE. OE.MAINTENANCE Authorized users of the TOE must ensure that the comprehensive diagnostics facilities provided by the product are invoked at every scheduled preventative maintenance period. OE.PHYSICAL Those responsible for the TOE must ensure that those parts of the TOE critical to enforcement of the security policy are protected from physical attack that might compromise IT security objectives. The protection must be commensurate with the value of the IT assets protected by the TOE. Page 21 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z OE.RECOVER Those responsible for the TOE must ensure that procedures and/or mechanisms are provided to assure that after system failure or other discontinuity, recovery without a protection (security) compromise is achieved. OE.TRUSTED.IT.SYSTEM The remote trusted IT systems implement the protocols and mechanisms required by the TSF to support the enforcement of the security policy. These remote trusted IT systems are under the same management domain as the TOE, are managed based on the same rules and policies applicable to the TOE, and are physically and logically protected equivalent to the TOE. 4.3 Security Objectives Rationale 4.3.1 Coverage The following table provides a mapping of TOE objectives to threats and policies, showing that each objective counters or enforces at least one threat or policy, respectively. Threats / OSPs Objective P.ACCOUNTABILITY O.AUDITING T.ACCESS.TSFDATA T.ACCESS.USERDATA T.ACCESS.TSFFUNC O.CRYPTO.NET T.ACCESS.TSFDATA T.ACCESS.USERDATA O.DISCRETIONARY .ACCESS T.RESTRICT.NETTRAFFIC O.NETWORK.FLOW T.ACCESS.TSFDATA T.ACCESS.USERDATA O.SUBJECT.COM T.IA.MASQUERADE T.IA.USER O.I&A T.ACCESS.TSFFUNC P.ACCOUNTABILITY P.USER O.MANAGE T.ACCESS.COMM O.TRUSTED_CHANNEL T.ACCESS.CP.USERDATA O.CP.USERDATA P.CP.ANCHOR O.CP.ANCHOR Table 2: Mapping of security objectives to threats and policies The following table provides a mapping of the objectives for the Operational Environment to assumptions, threats and policies, showing that each objective holds, counters or enforces at least one assumption, threat or policy, respectively. Page 22 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Assumptions / Threats / OSPs Objective A.MANAGE A.AUTHUSER A.TRAINEDUSER OE.ADMIN A.CONNECT T.ACCESS.COMM OE.REMOTE A.PHYSICAL A.MANAGE A.AUTHUSER A.TRAINEDUSER P.USER P.PROTECT_SSH_KEY OE.INFO_PROTECT A.MANAGE A.DETECT OE.INSTALL A.DETECT OE.MAINTENANCE A.PHYSICAL OE.PHYSICAL A.MANAGE A.DETECT OE.RECOVER A.PEER.MGT A.PEER.FUNC A.CONNECT OE.TRUSTED.IT.SYSTEM Table 3: Mapping of security objectives for the Operational Environment to assumptions, threats and policies 4.3.2 Sufficiency The following rationale provides justification that the security objectives are suitable to counter each individual threat and that each security objective tracing back to a threat, when achieved, actually contributes to the removal, diminishing or mitigation of that threat: Rationale for security objectives Threat The threat of accessing TSF data without proper authorization is removed by: T.ACCESS.TSFDATA ● O.CRYPTO.NET requiring cryptographically-protected communication channels for data including TSF data controlled by the TOE in transit between trusted IT systems. ● O.DISCRETIONARY .ACCESS requiring that data, including TSF data stored with the TOE, have discretionary access control protection. ● O.SUBJECT.COM requiring the TSF to mediate communication between subjects. The threat of accessing user data without proper authorization is removed by: T.ACCESS.USERDATA ● O.CRYPTO.NET requiring cryptographically-protected communication channels for data including user data controlled by the TOE in transit between trusted IT systems. Page 23 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Rationale for security objectives Threat ● O.DISCRETIONARY .ACCESS requiring that data including user data stored with the TOE, have discretionary access control protection. ● O.SUBJECT.COM requiring the TSF to mediate communication between subjects. The threat of accessing TSF functions without proper authorization is removed by: T.ACCESS.TSFFUNC ● O.CRYPTO.NET requiring cryptographically-protected communication channels to limit which TSF functions are accessible to external entities. ● O.MANAGE requiring that only authorized users utilize management TSF functions. The threat of accessing a communication channel that establishes a trust relationship between the TOE and another remote trusted IT system is removed by: T.ACCESS.COMM ● O.TRUSTED_CHANNEL requiring that the TOE implements a trusted channel between itself and a remote trusted IT system protecting the user data and TSF data transferred over this channel from disclosure and undetected modification and prevents masquerading of the remote trusted IT system. ● OE.REMOTE requiring that those systems providing the functions required by the TOE are sufficiently protected from any attack that may cause those functions to provide false results. The threat of accessing information or transmitting information to other recipients via network communication channels without authorization for this communication attempt is removed by: T.RESTRICT.NETTRAFFIC ● O.NETWORK.FLOW requiring the TOE to mediate the communication between itself and remote entities in accordance with its security policy. The threat of masquerading as an authorized entity in order to gain unauthorized access to user data, TSF data or TOE resources is removed by: T.IA.MASQUERADE ● O.I&A requiring that each entity interacting with the TOE is properly identified and authenticated before allowing any action the TOE is defined to provide to authenticated users only. The threat of accessing user data, TSF data or TOE resources without being identified and authenticated is removed by: T.IA.USER ● O.I&A requiring that each entity interacting with the TOE is properly identified and authenticated before allowing any action the TOE has defined to provide to authenticated users only. The threat of gaining access to user data at rest which is confidentiality protected without possessing the authorization of the owner, either at runtime of the TOE or when the TSF are inactive is removed by: T.ACCESS.CP.USERDATA Page 24 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Rationale for security objectives Threat ● O.CP.USERDATA requiring the TOE to be able to protect the confidentiality of user data at rest separately for each user. Table 4: Sufficiency of objectives countering threats The following rationale provides justification that the security objectives for the environment are suitable to cover each individual assumption, that each security objective for the environment that traces back to an assumption about the environment of use of the TOE, when achieved, actually contributes to the environment achieving consistency with the assumption, and that if all security objectives for the environment that trace back to an assumption are achieved, the intended usage is supported: Rationale for security objectives Assumption The assumption on the IT environment to provide the TOE with appropriate physical security, commensurate with the value of the IT assets protected by the TOE is covered by: A.PHYSICAL ● OE.INFO_PROTECT requiring the approval of network and peripheral cabling. ● OE.PHYSICAL requiring physical protection. The assumptions on the TOE security functionality being managed by one or more trustworthy individuals is covered by: A.MANAGE ● OE.ADMIN requiring trustworthy personnel managing the TOE. ● OE.INFO_PROTECT requiring personnel to ensure that information is protected in an appropriate manner. ● OE.INSTALL requiring personnel to ensure that components that comprise the system are distributed, installed and configured in a secure manner supporting the security mechanisms provided by the TOE. ● OE.RECOVER requiring personnel to assure that after system failure or other discontinuity, recovery without a protection (security) compromise is achieved. The assumption on authorized users to possess the necessary authorization to access at least some of the information managed by the TOE and to act in a cooperating manner in a benign environment is covered by: A.AUTHUSER ● OE.ADMIN ensuring that those responsible for the TOE are competent and trustworthy individuals, capable of managing the TOE and the security of the information it contains. ● OE.INFO_PROTECT requiring that DAC protections on security-relevant files (such as audit trails and authentication databases) shall always be set up correctly and that users are authorized to access parts of the data maintained by the TOE. The assumptions on users to be sufficiently trained and trusted to accomplish some task or group of tasks within a secure IT environment by exercising complete control over their user data is covered by: A.TRAINEDUSER ● OE.ADMIN requiring competent personnel managing the TOE. Page 25 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Rationale for security objectives Assumption ● OE.INFO_PROTECT requiring that those responsible for the TOE must establish and implement procedures to ensure that information is protected in an appropriate manner and that users are trained to exercise control over their own data. The assumption that modification or corruption of security-enforcing or security-relevant files will be detected by an administrative user is covered by: A.DETECT ● OE.INSTALL requiring an administrative user to ensure that the TOE is distributed, installed and configured in a secure manner supporting the security mechanisms provided by the TOE. ● OE.MAINTENANCE requiring an administrative user to ensure that the diagnostics facilities are invoked at every scheduled preventative maintenance period, verifying the correct operation of the TOE. ● OE.RECOVER requiring an administrative user to ensure that procedures and/or mechanisms are provided to assure that after system failure or other discontinuity, recovery without a protection (security) compromise is achieved. The assumption on all remote trusted IT systems to be under the same management control and operate under security policy constraints compatible with those of the TOE is covered by: A.PEER.MGT ● OE.TRUSTED.IT.SYSTEM requiring that these remote trusted IT systems are under the same management domain as the TOE, and are managed based on the same rules and policies applicable to the TOE. The assumption on all remote trusted IT systems to correctly implement the functionality used by the TSF consistent with the assumptions defined for this functionality is covered by: A.PEER.FUNC ● OE.TRUSTED.IT.SYSTEM requiring that the remote trusted IT systems implement the protocols and mechanisms required by the TSF to support the enforcement of the security policy. The assumption on all connections to and from remote trusted IT systems and between physically separate parts of the TSF not protected by the TSF itself are physically or logically protected is covered by: A.CONNECT ● OE.REMOTE requiring that remote trusted IT systems provide the functions required by the TOE and are sufficiently protected from any attack that may cause those functions to provide false results. ● OE.TRUSTED.IT.SYSTEM demanding the physical and logical protection equivalent to the TOE. Table 5: Sufficiency of objectives holding assumptions The following rationale provides justification that the security objectives are suitable to cover each individual organizational security policy, that each security objective that traces back to an OSP, when achieved, actually contributes to the implementation of the OSP, and that if all security objectives that trace back to an OSP are achieved, the OSP is implemented: Page 26 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Rationale for security objectives OSP The policy to hold users accountable for their security-relevant actions within the TOE is implemented by: P.ACCOUNTABILITY ● O.AUDITING providing the TOE with audit functionality. ● O.MANAGE allowing the management of this function. The policy to match the trust given to a user and the actions the user is given authority to perform is implemented by: P.USER ● O.MANAGE allowing appropriately-authorized users to manage the TSF. ● OE.INFO_PROTECT, which requires that users are trusted to use the protection mechanisms of the TOE to protect their data. The policy to match the trust given to a user to protect his SSH private key is implemented by: P.PROTECT_SSH_KEY ● OE.INFO_PROTECT, which requires that users are trusted to exercise the control over their own data. The policy that users shall control the confidentiality protection anchor for their confidentiality-protected user data, and reset/replace/modify it if desired is implemented by: P.CP.ANCHOR ● O.CP.ANCHOR allowing each user to manage the trust anchor for the confidentiality protection of his own user data. Table 6: Sufficiency of objectives enforcing Organizational Security Policies Page 27 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 5 Extended Components Definition The Security Target uses the extended components of FDP_RIP.3 as well as FIA_USB.2 defined by [OSPP]. They are not re-defined here again. The definition of FCS_RNG has supplied by BSI. In addition, the Security Target defines the extended component of the FDP_CDP family for usage within this ST. 5.1 Class FDP: User data protection 5.1.1 Confidentiality protection (FDP_CDP) Component levelling The FDP_CDP family contains only one component: FDP_CDP.1. FDP_CDP.1 is therefore not hierarchical to any other component within the FDP_CDP family. FDP_CDP.1 Confidentiality protection for data at rest, requires that the TSF ensures that the user data is stored within containers controlled by the TSF protected against accesses while the TSF are executing as well as when the TSF are not enforced. Management: FDP_CDP.1 The following actions could be considered for the management functions in FMT: a) Management of confidentiality protection trust anchor. Audit: FDP_CDP.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: The identity of any user or subject using the data storage mechanism. b) Basic: The identity of any unauthorised user or subject attempting to use the data exchange mechanisms. c) Detailed: The identity of any unauthorised user or subject attempting to use the data exchange mechanisms. 5.1.1.1 FDP_CDP.1 - Confidentiality for data at rest No other components. Hierarchical to: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control ] Dependencies: The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] to store user data at rest in containers controlled by the TSF in a manner protected from unauthorised disclosure. FDP_CDP.1.1 Rationale This family provides requirements that address the protection of the confidentiality of user data while it is at rest within containers controlled by the TSF. This family differs from FDP_UCT which covers the confidentiality to be maintained during the transmission of user data between the TOE and another IT product. Page 28 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 5.2 Class FCS: Cryptographic support 5.2.1 Random number generator (RNG) Family behaviour This family defines quality requirements for the generation of random numbers that are intended to be used for cryptographic purposes. Component levelling FCS_RNG.1 is not hierarchical to any other component within the FCS_RNG family. Management: FCS_RNG.1 The following actions could be considered for the management functions in FMT: a) There are no management activities foreseen. Audit: FCS_RNG.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: There are no actions defined to be auditable. b) Basic: There are no actions defined to be auditable. c) Detailed: There are no actions defined to be auditable. 5.2.1.1 FCS_RNG.1 - Random number generation No other components. Hierarchical to: No dependencies. Dependencies: The TSF shall provide a deterministic random number generator that implements: FCS_RNG.1.1 ● DRG.2.1: If initialized with a random seed [selection: using PTRNG of class PTG.2 as random source, using PTRNG of class PTG.3 as random source, using NPTRNG of class NTG.1 as random source, [assignment: other requirements for seeding]], the internal state of the RNG shall [selection: have [assignment: amount of entropy], have [assignment: work factor], require [assignment: guess work]]. ● DRG.2.2: The RNG provides forward secrecy. ● DRG.2.3: The RNG provides backward secrecy. The TSF shall provide random numbers that meet: FCS_RNG.1.2 ● DRG.2.4: The RNG initialized with a random seed [assignment: requirements for seeding] generates output for which [assignment: number of strings] strings of bit length 128 are mutually different with probability [assignment: probability]. ● DRG.2.5: Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass test procedure A [assignment: additional test suites]. Rationale Page 29 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z The quality of the random number generator is defined using this SFR. The quality metric required in FCS_RNG.1.2 is detailed in the German Scheme AIS 20 and AIS 31 and amended based on discussions with BSI. Page 30 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 6 Security Requirements 6.1 TOE Security Functional Requirements All of the following SFRs are derived from the OSPP. The SFRs taken from OSPP are instantiated exactly as the OSPP would require it. Therefore, some SFRs may contain spurious "no other rule" or similar assignments which would make no sense if the SFRs are derived from CC part 2. As this ST will be reused in a later evaluation to be fully OSPP compliant, the ST author decided to already apply all OSPP requirements to the instantiated SFRs. The following table shows the Security functional requirements for the TOE, and the operations performed on the components according to CC part 2: iteration (Iter.), refinement (Ref.), assignment (Ass.) and selection (Sel.). Operations Source Base security functional component Security functional requirement Security functional group Sel. Ass. Ref. Iter. No Yes No No OSPP FAU_GEN.1 Audit data generation General-purpose computing environment No No No No OSPP FAU_GEN.2 User identity association No Yes No No OSPP FAU_SAR.1 Audit review No No No No OSPP FAU_SAR.2 Restricted audit review No Yes No No OSPP FAU_SEL.1 Selective audit Yes No No No OSPP FAU_STG.1 Protected audit trail storage No Yes Yes No OSPP FAU_STG.3 Action in case of possible audit data loss Yes Yes Yes No OSPP FAU_STG.4 Prevention of audit data loss No Yes Yes No OSPP FCS_CKM.1 FCS_CKM.1(SYM) Cryptographic key generation No Yes No No OSPP FCS_CKM.1 FCS_CKM.1(RSA) Cryptographic key generation Yes Yes No No OSPP FCS_CKM.1 FCS_CKM.1(DSA) Cryptographic key generation Yes No No No OSPP FCS_CKM.2 FCS_CKM.2(NET) Cryptographic key distribution No Yes No No OSPP FCS_CKM.4 Cryptographic key destruction Yes No No No OSPP FCS_COP.1 FCS_COP.1(NET) Cryptographic operation No Yes No Yes CC Part 2 FCS_COP.1 FCS_COP.1(CP) Cryptographic operation Page 31 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Operations Source Base security functional component Security functional requirement Security functional group Sel. Ass. Ref. Iter. Yes Yes No No ECD FCS_RNG.1 FCS_RNG.1(SSH-DFLT) Random number generation (Class DRG.2) Yes Yes Yes No ECD FCS_RNG.1 FCS_RNG.1(SSH-FIPS) Random number generation (Class DRG.2) Yes Yes No No ECD FCS_RNG.1 FCS_RNG.1(DM) Random number generation (Class DRG.2) No Yes No No OSPP FDP_ACC.1 FDP_ACC.1(PSO) Subset access control No Yes No No OSPP FDP_ACC.1 FDP_ACC.1(TSO) Subset access control No Yes No No OSPP FDP_ACF.1 FDP_ACF.1(PSO) Security attribute based access control No Yes No No OSPP FDP_ACF.1 FDP_ACF.1(TSO) Security attribute based access control No Yes No No OSPP FDP_IFC.2 FDP_IFC.2(NI) Complete information flow control Yes Yes Yes No OSPP FDP_IFF.1 FDP_IFF.1(NI-IPTables) Simple security attributes Yes Yes Yes No OSPP FDP_IFF.1 FDP_IFF.1(NI-ebtables) Simple security attributes No Yes No No OSPP FDP_ITC.2 FDP_ITC.2(BA) Import of user data with security attributes Yes No No No OSPP FDP_RIP.2 Full residual information protection Yes No No No OSPP FDP_RIP.3 Full residual information protection of resources Yes Yes No No OSPP FIA_AFL.1 Authentication failure handling No Yes No No OSPP FIA_ATD.1 FIA_ATD.1(HU) User attribute definition No Yes No No OSPP FIA_ATD.1 FIA_ATD.1(TU) User attribute definition No No No No OSPP FIA_SOS.1 Verification of secrets No Yes No No OSPP FIA_UAU.1 Timing of authentication No Yes No No OSPP FIA_UAU.5 Multiple authentication mechanisms Page 32 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Operations Source Base security functional component Security functional requirement Security functional group Sel. Ass. Ref. Iter. No No No No OSPP FIA_UAU.7 Protected authentication feedback No Yes No No OSPP FIA_UID.1 Timing of identification No Yes No No OSPP FIA_USB.2 Enhanced user-subject binding No No No No OSPP FPT_STM.1 Reliable time stamps No Yes No No OSPP FPT_TDC.1 FPT_TDC.1(BA) Inter-TSF basic TSF data consistency No Yes No No OSPP FTA_SSL.1 TSF-initiated session locking No Yes No No OSPP FTA_SSL.2 User-initiated locking Yes Yes No No OSPP FTP_ITC.1 Inter-TSF trusted channel No Yes No Yes CC Part 2 FDP_ACC.2 FDP_ACC.2(CP) Complete access control Confidentiality protection of data at rest No Yes No Yes CC Part 2 FDP_ACF.1 FDP_ACF.1(CP) Security attribute based access control No Yes No No ECD FDP_CDP.1 FDP_CDP.1(CP) Confidentiality for data at rest Yes Yes No No OSPP FMT_MSA.1 FMT_MSA.1(PSO) Management of object security attributes Management related functionality No Yes No No OSPP FMT_MSA.1 FMT_MSA.1(TSO) Management of object security attributes Yes Yes No Yes CC Part 2 FMT_MSA.1 FMT_MSA.1(CP) Management of security attributes No Yes No No OSPP FMT_MSA.3 FMT_MSA.3(PSO) Static attribute initialisation No Yes No No OSPP FMT_MSA.3 FMT_MSA.3(TSO) Static attribute initialisation Yes Yes No No OSPP FMT_MSA.3 FMT_MSA.3(NI) Static attribute initialisation Yes Yes No Yes CC Part 2 FMT_MSA.3 FMT_MSA.3(CP) Static attribute initialisation No Yes No No OSPP FMT_MSA.4 FMT_MSA.4(PSO) Security attribute value inheritance No Yes No No OSPP FMT_MTD.1 FMT_MTD.1(AE) Management of TSF data Page 33 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Operations Source Base security functional component Security functional requirement Security functional group Sel. Ass. Ref. Iter. Yes Yes No No OSPP FMT_MTD.1 FMT_MTD.1(AS) Management of TSF data Yes Yes No No OSPP FMT_MTD.1 FMT_MTD.1(AT) Management of TSF data Yes Yes No No OSPP FMT_MTD.1 FMT_MTD.1(AF) Management of TSF data Yes Yes No No OSPP FMT_MTD.1 FMT_MTD.1(NI) Management of TSF data No Yes No No OSPP FMT_MTD.1 FMT_MTD.1(IAT) Management of TSF data No Yes No No OSPP FMT_MTD.1 FMT_MTD.1(IAF) Management of TSF data No Yes No No OSPP FMT_MTD.1 FMT_MTD.1(IAU) Management of TSF data Yes Yes No Yes CC Part 2 FMT_MTD.1 FMT_MTD.1(SSH) Management of TSF data Yes Yes No Yes CC Part 2 FMT_MTD.1 FMT_MTD.1(SSL) Management of TSF data Yes Yes No Yes CC Part 2 FMT_MTD.1 FMT_MTD.1(CP-AN) Management of TSF data Yes Yes No Yes CC Part 2 FMT_MTD.1 FMT_MTD.1(CP-UD) Management of TSF data No Yes No No OSPP FMT_REV.1 FMT_REV.1(OBJ) Revocation No Yes No No OSPP FMT_REV.1 FMT_REV.1(USR) Revocation No Yes No No OSPP FMT_SMF.1 Specification of management functions No Yes No No CC Part 2 FMT_SMR.1 Security management roles Table 7: Security functional requirements for the TOE 6.1.1 General-purpose computing environment 6.1.1.1 Audit data generation (FAU_GEN.1) The TSF shall be able to generate an audit record of the following auditable events: FAU_GEN.1.1 a) Start-up and shutdown of the audit functions; b) All auditable events for the basic level of audit; and c) all modifications to the set of events being audited; Page 34 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z d) all user authentication attempts; e) all denied accesses to objects for which the access control policy defined in the OSPP base applies; f) explicit modifications of access rights to objects covered by the access control policies; and g) no additional events . The TSF shall record within each audit record at least the following information: FAU_GEN.1.2 a) Date and time of the event, type of event, subject identity (if applicable), and outcome 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; i. User identity (if applicable); and ii. no additional information . 6.1.1.2 User identity association (FAU_GEN.2) For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event. FAU_GEN.2.1 Application Note: The TOE maintains a "Login UID", which is inherited by every new process spawned. This allows the TOE to identify the "real" originator of an event, regardless if he has changed his real and / or effective and filesystem UID e. g. using the su command or executing a setuid or setgid program. 6.1.1.3 Audit review (FAU_SAR.1) The TSF shall provide the root user with the capability to read all audit information from the audit records. FAU_SAR.1.1 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. FAU_SAR.1.2 Application Note: The audit records are stored in ASCII format and can therefore be read with a normal editor or pager. In addition, the TOE provides specific tools that support the interpretation of the audit trail. Application Note: The audit trail is stored in a file that is readable to the root user only. 6.1.1.4 Restricted audit review (FAU_SAR.2) The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access. FAU_SAR.2.1 Application Note: The protection of the audit records is based on the Unix permission bit settings defined by FDP_ACC.1(PSO) supported by FDP_ACF.1(PSO). 6.1.1.5 Selective audit (FAU_SEL.1) The TSF shall be able to select the set of events to be audited from the set of all auditable events based on the following attributes: FAU_SEL.1.1 a) Type of audit event; b) Subject or user identity; c) Outcome (success or failure) of the audit event; d) Named object identity; Page 35 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z e) Access types on a particular object; f) System call number; g) Event type; h) Host identity; Application Note: The TOE provides an application that allows specification of the audit rules which injects the rules into the kernel for enforcement. The Linux kernel auditing mechanism obtains all audit events and decides based on this rule set whether an event is forwarded to the audit daemon for storage. 6.1.1.6 Protected audit trail storage (FAU_STG.1) The TSF shall protect the stored audit records in the audit trail from unauthorised deletion. FAU_STG.1.1 The TSF shall be able to prevent unauthorised modifications to the audit records in the audit trail. FAU_STG.1.2 Application Note: The protection of the audit records is based on the Unix permission bit settings defined by FDP_ACC.1(PSO) supported by FDP_ACF.1(PSO). The audit trail is readable and writeable to the root user only. Application Note: FAU_STG.1(AUD) from the OSPP extended package for auditing is merged with this SFR. 6.1.1.7 Action in case of possible audit data loss (FAU_STG.3) The TSF shall notify an authorized administrator if the audit trail exceeds a root-user selectable, pre-defined size limit of the audit trail or if any of the following condition is detected that may result in a loss of audit records: no other condition. FAU_STG.3.1 Application Note: The term "authorized administrator" refers to the user that is notified by the auditd daemon. This daemon can be configured to notify different users in different ways. The administrator of the system must ensure that the auditd is configured to send the notification to the intended recipient. Application Note: The alarm generated by the TOE can be configured to be a syslog message or the execution of an administrator-specified application. This message or action of executing the application is generated when the audit trail capacity exceeds the limit defined in the auditd.conf file. Application Note: The information of the threshold limit is done in the configuration file of the auditd daemon. This file is only writeable to the root user. 6.1.1.8 Prevention of audit data loss (FAU_STG.4) The TSF shall be able to ignore the audited events and perform one of the following administrator-defined actions: FAU_STG.4.1 a) Stop all processes that attempt to generate an audit record; b) Switch to single user mode; c) Halt the system if the audit trail is full. Page 36 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Application Note: The SFR lists all configuration possibilities that apply to the case when the audit trail is full (i.e. the disk is full). Even though the SFR mentions the "ignoring of audit events" separate from the other options, all options should be seen as equal where the root user can select one of these options. 6.1.1.9 Cryptographic key generation (FCS_CKM.1(SYM)) The TSF shall generate symmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm capable of generating a random bit sequence and specified cryptographic key sizes: FCS_CKM.1.1 a) AES128 bits, b) Triple-DES168 bits, c) AES256 bits, d) Twofish, Serpent: 128 bits, 192 bits, and 256 bits, e) AES: 192 bits that meet the following: cryptographic key generation algorithm based on the random number generator a) FCS_RNG.1(SSH-DFLT) for use in OpenSSH applications when FIPS 140-2 mode is not configured; b) FCS_RNG.1(SSH-FIPS) for use in OpenSSH applications when FIPS 140-2 mode is configured; c) FCS_RNG.1(DM) for use during initialization of confidentiality-protected disks. 6.1.1.10 Cryptographic key generation (FCS_CKM.1(RSA)) The TSF shall generate RSA cryptographic keys in accordance with a specified cryptographic key generation algorithm defined in U.S. NIST FIPS PUB 186-3 appendix B.3 and specified cryptographic key sizes: FCS_CKM.1.1 a) 2048 bits, b) 1024 bits, c) 3072 bits that meet the following: a) U.S. NIST FIPS PUB 186-3, b) no other standard. Application Note: The TOE supports the generation of RSA keys for the OpenSSH host key as well as the OpenSSH user keys using the ssh-keygen(1) application. 6.1.1.11 Cryptographic key generation (FCS_CKM.1(DSA)) The TSF shall generate DSA cryptographic keys in accordance with a specified cryptographic key generation algorithm defined in U.S. NIST FIPS PUB 186-3 appendix B.1 and specified cryptographic key sizes: FCS_CKM.1.1 a) L=1024, N=160 bits; that meet the following: a) U.S. NIST FIPS PUB 186-3, b) no other standard. Application Note: Page 37 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z The TOE supports the generation of DSA keys for the OpenSSH host key as well as the OpenSSH user keys using the ssh-keygen(1) application. 6.1.1.12 Cryptographic key distribution (FCS_CKM.2(NET)) The TSF shall distribute cryptographic keys in accordance with the following specified cryptographic key distribution method that meets the following: FCS_CKM.2.1 a) Diffie-Hellman key agreement method defined for the SSH protocol by RFC4253; b) Public DSS, RSA host key exchange defined for the SSH protocol by RFC4253; Application Note: DSS defined in RFC4253 for the host key exchange is compliant with DSA defined in FIPS 186-3. 6.1.1.13 Cryptographic key destruction (FCS_CKM.4) The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method of zerorization that meets the following: vendor-specific zeroization. FCS_CKM.4.1 Application Note: The "vendor-specific zeroization" covers to the following concepts: ● Memory objects: Overwriting the memory with zeros at the time the memory is released. ● Asymmetric key components stored in files: The object reuse functionality for objects defined with FDP_RIP.2 also covers this SFR. 6.1.1.14 Cryptographic operation (FCS_COP.1(NET)) The TSF shall perform encryption, decryption, integrity verification, peer authentication in accordance with the following cryptographic algorithms, cryptographic key sizes and applicable standards: FCS_COP.1.1 a) SSH allowing the use of TDES in CBC mode with 168 bits key size, and HMAC-SHA1 defined by RFC 4253; b) SSH allowing the use of AES in CBC mode with 128 bits and 256 bits key size, and HMAC-SHA1 defined by RFC 4253; c) SSH allowing the use of AES in CBC mode with 192 bits key size, and HMAC-SHA1 defined by RFC 4253; d) SSH allowing the use of AES in CTR mode with 128 bits, 192 bits and 256 bits key size, and HMAC-SHA1 defined by RFC 4253; e) SSH allowing the use of DSA with L=1024 bits, N=160 bits with the format of ssh-dss for "publickey" authentication defined by RFC 4252; f) SSH allowing the use of RSA with key sizes of 1024 bits, 2048 bits, 3072 bits with the format of ssh-rsa for "publickey" authentication defined by RFC 4252; Page 38 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 6.1.1.15 Cryptographic operation (FCS_COP.1(CP)) The TSF shall perform encryption, decryption, integrity verification in accordance with a specified cryptographic algorithm formed with any permutation of the following types of cryptographic primitives: FCS_COP.1.1 a) Ciphers: AES, Serpent, Twofish; b) Message Digest: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512; c) Block chaining modes: CBC; d) IV-Handling mechanisms: 1. CBC: essiv - The sector number is encrypted with the bulk cipher using a salt as key. The salt is derived from the cipher key used for encrypting the data with via hashing. and cryptographic key sizes as allowed by the cipher specifications that meet the following: LUKS-based dm-crypt Linux partition encryption schema. 6.1.1.16 Random number generation (Class DRG.2) (FCS_RNG.1(SSH-DFLT)) The TSF shall provide a deterministic random number generator that implements: FCS_RNG.1.1 a) DRG2.1: If initialized with a random seed using /dev/random as seed source , the internal state of the RNG shall have a minimum entropy of 48 bits. b) DRG2.2: The DRNG provides forward secrecy. c) DRG2.3: The DRNG provides backward secrecy. The TSF shall provide random numbers that meet: FCS_RNG.1.2 a) DRG.2.4: The RNG initialized with a random seed holding 96 bits of entropy generates output for which 2**25 strings of bit length 128 are mutually different with probability of greater than 1-2**-10. b) DRG.2.5: Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass test procedure A. Application Note: The OpenSSH applications use the deterministic RNG from OpenSSL to generate random numbers. Every time the ssh client is invoked, the ssh-keygen application is used or a new SSH connection is processed by sshd, the deterministic random number generator is seeded with data from /dev/random. Application Note: NPTRNG is the abbreviation for non-physical true random number generator. 6.1.1.17 Random number generation (Class DRG.2) (FCS_RNG.1(SSH-FIPS)) The TSF shall provide a deterministic random number generator using the ANSI X9.31 Appendix A2.4 standard with AES-128 core that implements: FCS_RNG.1.1 a) DRG2.1: If initialized with a random seed using /dev/random seed source , the internal state of the RNG shall have a minimum entropy of 48 bits. b) DRG2.2: The DRNG provides forward secrecy. Page 39 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z c) DRG2.3: The DRNG provides backward secrecy. The TSF shall provide random numbers that meet: FCS_RNG.1.2 a) DRG.2.4: The RNG initialized with a random seed holding 96 bits of entropy generates output for which 2**25 strings of bit length 128 are mutually different with probability of greater than 1-2**-10 . b) DRG.2.5: Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass test procedure A. Application Note: The OpenSSH applications use the deterministic RNG from OpenSSL to generate random numbers. Every time the ssh client is invoked, the ssh-keygen application is used or a new SSH connection is processed by sshd, the deterministic random number generator is seeded with data from /dev/random. Note, the OpenSSL library provides two separate deterministic RNGs, the default used in normal mode and an ANSI X9.31 compliant DRNG in FIPS 140-2 mode. This SFR covers the DRNG provided in FIPS 140-2 mode. 6.1.1.18 Random number generation (Class DRG.2) (FCS_RNG.1(DM)) The TSF shall provide a deterministic random number generator that implements: FCS_RNG.1.1 a) DRG2.1: If initialized with a random seed using /dev/random of class DRG.3 as random source , the internal state of the RNG shall have a minimum entropy of 48 bits. b) DRG2.2: The DRNG provides forward secrecy. c) DRG2.3: The DRNG provides backward secrecy. The TSF shall provide random numbers that meet: FCS_RNG.1.2 a) DRG.2.4: The RNG initialized with a random seed holding 96 bits of entropy generates output for which 2**25 strings of bit length 128 are mutually different with probability of greater than 1-2**-10 . b) DRG.2.5: Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass test procedure A. Application Note: The libcryptsetup library reads 13 bytes off /dev/random and XORs the obtained data byte-wise with the random number state of the provided by libgcrypt. libgcrypt automatically seeds from /dev/urandom, however, this SFR covers the quality of the seed provided with /dev/random. 6.1.1.19 Subset access control (FDP_ACC.1(PSO)) The TSF shall enforce the Persistent Storage Object Access Control Policy on FDP_ACC.1.1 a) Subjects: all subjects defined with the Security Policy Model; b) Objects: i. Persistent Storage Objects of the following type: all file system objects defined with the Security Policy Model; ii. no other storage objects; c) Operations: read, write, execute (regular files), search (directories). Page 40 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 6.1.1.20 Subset access control (FDP_ACC.1(TSO)) The TSF shall enforce the Transient Storage Object Access Control Policy on FDP_ACC.1.1 a) Subjects: all subjects defined with the Security Policy Model; b) Objects: i. Transient Storage Objects of the following type: all IPC objects defined with the Security Policy Model; ii. no other storage objects; c) Operations: read, receive, write, send. 6.1.1.21 Security attribute based access control (FDP_ACF.1(PSO)) The TSF shall enforce the Persistent Storage Object Access Control Policy to objects based on the following: FDP_ACF.1.1 a) Subject security attributes: file system UID, file system GID, supplemental GIDs; b) Object security attributes: owning UID, owning GID; c) Access control security attributes maintained for each file system object governing access to that object: i. ACL for specific UIDs (ACL_USER), ii. ACL for specific GIDs (ACL_GROUP), iii. Maximum ACL for the file system object (ACL_MASK), iv. Permission bits for the owning UID (equals to ACL_USER_OBJ when using ACLs), v. Permission bits for the owning GID (equals to ACL_GROUP_OBJ when using ACLs), vi. Permission bits for "world" (equals to ACL_OTHER when using ACLs), vii. The following permission bits: read, write, execute (for files), search (for directories), viii. The following access rights applicable to the file system object: SAVETXT (directories), immutable (files), d) Access control security attributes maintained for each partition holding a file system: read-only; The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: A subject must have search permission for every element of the pathname and the requested access for the object. A subject has a specific type access to an object if one of the following rules hold (the order of the rules is applicable on a first-match basis): FDP_ACF.1.2 a) The subject's filesystem UID is identical with the owning UID of the object and the requested type of access is within the permission bits defined for the owning UID (permission bits) or by ACL_USER_OBJ (ACLs); or b) ACLs: The subject's filesystem UID is identical with the UID specified with ACL_USER of the object and the requested type of access is within the permission bits defined in ACL_USER; or Page 41 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z c) The subject's filesystem GID or one of the subject's supplemental GIDs identical with the owning GID and the requested type of access is within the permission bits defined for the owning GID (permission bits), or by ACL_GROUP_OBJ when there is no ACL_MASK entry (ACLs), or by the ACL_MASK entry (ACLs); or d) ACLs: The subject's filesystem GID or one of the subject's supplemental GIDs is identical with the GID specified with ACL_GROUP of the object and the requested type of access is within the permission bits defined in ACL_GROUP; or e) The requested type of access is within the permission bits defined for "world" (permission bits) or by ACL_OTHER (ACLs). Application Note: The permission bits and the ACLs are inherently consistent as the TOE assigns the permission bits to ACLs when ACLs are used. Without any ACLs specified for an object, the TOE only uses the permission bits. If at least one ACL is present or when the ACL management tools are applied for objects even without any ACL set, the permission bits are interpreted as outlined above: the ACL entry of ACL_USER_OBJ contains the owning UID permission bits, the ACL entry of ACL_GROUP_OBJ contains the owning GID permission bits, and the ACL entry of ACL_OTHER contains the permission bits for "world". The ACL entries of ACL_USER_OBJ, ACL_GROUP_OBJ and ACL_OTHER are only a different representation of the permission bits to users, they are not separate attributes in addition to permission bits. The explicit specification of ACL_USER_OBJ, ACL_GROUP_OBJ and ACL_OTHER in the rule set above in addition to the permission bits is only intended to aid the evaluator or reader in understanding the overall ruleset. Application Note: Due to the fact that the permission bits are an inherent part of the ACLs, there is no precedence issue between permission bits and ACLs. The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: FDP_ACF.1.3 a) read and directory search operations are allowed for the subject with the capability of CAP_DAC_READ_SEARCH; b) write and execute operations are allowed for the subject with the capability of CAP_DAC_OVERRIDE - the execute permission is granted if the file system object object is marked with at least one executable bit in its permission settings. The TSF shall explicitly deny access of subjects to named objects based on the following rules: FDP_ACF.1.4 a) Any file system object in a file system that is mounted as read-only cannot be modified, created or removed, b) A file, a directory and a symbolic link in a file system that is mounted as read-only cannot be written to, c) Any file system object marked as immutable cannot be modified or removed, d) Any file system object stored in a directory marked with the SAVETXT bit cannot be modified or removed by subjects whose file system UID is not equal to the owning UID of the file system object unless the subject performing the operation possesses the CAP_FOWNER capability. Page 42 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 6.1.1.22 Security attribute based access control (FDP_ACF.1(TSO)) The TSF shall enforce the Transient Storage Object Access Control Policy to objects based on the following: FDP_ACF.1.1 a) Subject security attributes: effective UID, file system UID, effective GID, file system GID, supplemental GIDs; b) Object security attributes: owning UID, owning GID; c) Access control security attributes maintained for each IPC object whose name is managed with a file governing access to that object: see FDP_ACF.1(PSO); d) Access control security attributes maintained for any other IPC object governing access to that object: i. Permission bits for the owning UID, ii. Permission bits for the owning GID, iii. Permission bits for "world", iv. The following permission bits: read, write, execute, The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: FDP_ACF.1.2 a) IPC object whose name is managed with a file: see FDP_ACF.1(PSO); b) Any other IPC object: A subject has a specific type access to an object if one of the following rules hold (the order of the rules is applicable on a first-match basis): 1. The subject's effective UID is identical with the owning UID of the object and the requested type of access is within the permission bits defined for the owning UID; or 2. The subject's effective GID or one of the subject's supplemental GIDs identical with the owning GID and the requested type of access is within the permission bits defined for the owning GID; or 3. The requested type of access is within the permission bits defined for "world". The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: FDP_ACF.1.3 a) IPC object whose name is managed with a file: see FDP_ACF.1(PSO); b) Any other IPC object: 1. read and receive operations are allowed for the subject with the capability of CAP_DAC_READ_SEARCH; 2. write and send operations are allowed for the subject with the capability of CAP_DAC_OVERRIDE. The TSF shall explicitly deny access of subjects to named objects based on the following rules: FDP_ACF.1.4 a) IPC object whose name is managed with a file: see FDP_ACF.1(PSO); b) Any other IPC object: none. Page 43 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 6.1.1.23 Complete information flow control (FDP_IFC.2(NI)) The TSF shall enforce the Network Information Flow Control Policy on FDP_IFC.2.1 a) Subjects: i. unauthenticated external IT entities that send and receive information mediated by the TOE; ii. standard Linux processes that send and receive information mediated by the TOE; b) Information: i. Network data routed through the TOE; ii. No other information; and all operations that cause that information to flow to and from subjects covered by the SFP. The TSF shall ensure that all operations that cause any information in the TOE to flow to and from any subject in the TOE are covered by an information flow control SFP. FDP_IFC.2.2 Application Note: The SFR applies only to host systems which implements the packet filtering functionality. 6.1.1.24 Simple security attributes (FDP_IFF.1(NI-IPTables)) The TSF shall enforce the Network Information Flow Control Policy based on the following types of subject and information security attributes: FDP_IFF.1.1 a) ObjectInformation security attribute: the logical or physical network interface through which the network data entered the TOE; b) TCP/IP information security attributes: i. Source and destination IP address, ii. Source and destination TCP port number, iii. Source and destination UDP port number, iv. Network protocol of IP, TCP, UDP, ICMP v. TCP header flags of SYN, ACK, FIN, RST, URG, PSH vi. TCP sequence numbers; c) Information security attribute: IP packet identified as to be routed by the TSF. Application Note: The refinement is applied due to an obvious error in the OSPP. The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: If the packet filter matches the analyzed packet and the rule accepts the packet, the packet is forwarded according to the network protocol stack's behavior. FDP_IFF.1.2 The TSF shall enforce the following rules: Identification of network data using one or more of the following concepts: FDP_IFF.1.3 a) Information security attribute matching; b) Matching based on the state of a TCP connection, Statistical analysis matching; Performing one or more of the following actions with identified network data: Page 44 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z a) Discard the network data without any further processing, with sending a notification to the sender; b) Allow the network data to be processed unaltered by the TOE according to the routing information maintained by the TOE; c) No other actions. The TSF shall explicitly authorise an information flow based on the following rules: If the network data is not matched by the rule set and the default rule of the packet filter is ACCEPT then the data is forwarded unaltered based on the normal operation of the host system's networking stack. FDP_IFF.1.4 The TSF shall explicitly deny an information flow based on the following rules: If the network data is not matched by the rule set, one of the following default rules applies: FDP_IFF.1.5 a) DROP: the data is discarded; b) REJECT: then the data is discarded and a notification is returned to the sender. Application Note: The default rule is configurable where exactly one of the above mentioned default rules can be selected at any given time. Application Note: The SFRs FDP_IFF.1(NI-iptables) and FDP_IFF.1(NI-ebtables) both define different rule sets implemented by the TOE covering the FDP_IFF.1(NI) SFR from the OSPP base. 6.1.1.25 Simple security attributes (FDP_IFF.1(NI-ebtables)) The TSF shall enforce the Network Information Flow Control Policy based on the following types of subject and information security attributes: FDP_IFF.1.1 a) ObjectInformation security attribute: the logical or physical network interface through which the network data entered the TOE; b) TCP/IP information security attributes: i. Source and destination IP address, ii. Source and destination TCP port number, iii. Source and destination UDP port number, iv. Network protocol of IP, TCP, UDP v. TCP header flags of TOS vi. Ethernet frames security attributes: i. Source and destination MAC address, ii. Ethernet protocol type. The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: If the packet filter matches the analyzed packet and the rule accepts the packet, the packet is forwarded according to the network protocol stack's behavior. FDP_IFF.1.2 The TSF shall enforce the following rules: Identification of network data using one or more of the following concepts: FDP_IFF.1.3 a) Information security attribute matching; b) No other concepts; Performing one or more of the following actions with identified network data: a) Discard the network data without any further processing; Page 45 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z b) Allow the network data to be processed unaltered by the TOE according to the routing information maintained by the TOE; c) No other actions. The TSF shall explicitly authorise an information flow based on the following rules: If the network data is not matched by the rule set and the default rule of the packet filter is ACCEPT then the data is forwarded unaltered based on the normal operation of the host system's networking stack. FDP_IFF.1.4 The TSF shall explicitly deny an information flow based on the following rules: If the network data is not matched by the rule set, and the default rule of the packet filter is DROP then the data is discarded. FDP_IFF.1.5 Application Note: The default rule is configurable where exactly one of the above mentioned default rules can be selected at any given time. 6.1.1.26 Import of user data with security attributes (FDP_ITC.2(BA)) The TSF shall enforce the Persistent Storage Access Control Policy, Transient Storage Access Control Policy,Network Information Flow Control, no other access control SFP(s) and/or information flow control SFP(s) when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.2.1 The TSF shall use the security attributes associated with the imported user data. FDP_ITC.2.2 The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received. FDP_ITC.2.3 The TSF shall ensure that interpretation of the security attributes of the imported user data is as intended by the source of the user data. FDP_ITC.2.4 The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: No additional importation control rules. FDP_ITC.2.5 6.1.1.27 Full residual information protection (FDP_RIP.2) The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to all objects. FDP_RIP.2.1 6.1.1.28 Full residual information protection of resources (FDP_RIP.3) The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to all subjects or users. FDP_RIP.3.1 Application Note: The subject is represented by the data structures inside the kernel forming a process: all data structures anchored in the task_struct. The user is represented by its attributes defined by FIA_ATD.1. 6.1.1.29 Authentication failure handling (FIA_AFL.1) The TSF shall detect when an administrator-configurable number of unsuccessful authentication attempts for the authentication method of password-based authentication occur related to consecutive unsuccessful authentication attempts. FIA_AFL.1.1 Page 46 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z When the defined number of unsuccessful authentication attempts has been met, surpassed, the TSF shall FIA_AFL.1.2 a) For all administrator accounts, "disable" the account for an authorized administrator configurable time period such that there can be no more than ten attempts per minute. b) For all other accounts, disable the user logon account until it is re-enabled by the authorized administrator. c) For all disabled accounts, any response to an authentication attempt given to the user shall not be based on the result of that authentication attempt. 6.1.1.30 User attribute definition (FIA_ATD.1(HU)) The TSF shall maintain the following list of security attributes belonging to individual human users: FIA_ATD.1.1 a) User identifier; b) Group memberships; c) User password; d) Software token verification data; e) Security roles; f) no other attributes. Application Note: Please see the application note for FIA_UAU.5 for a list of token-based authentication mechanisms and their associated tokens. 6.1.1.31 User attribute definition (FIA_ATD.1(TU)) The TSF shall maintain the following list of security attributes belonging to individual technical users: FIA_ATD.1.1 a) the logical or physical network interface through which the network data entered the TOE; b) identity of the logical or physical external interface through which the user connected to the TOE; c) no other security attributes. Application Note: Bullet a) of this SFR relates to FDP_IFC.2(NI) and the supporting information flow control rules specified with the iterations of FDP_IFF.1. In the Common Criteria scheme, external entities are always considered to be users. Therefore, every network data entity must be specified as user in this ST. 6.1.1.32 Verification of secrets (FIA_SOS.1) The TSF shall provide a mechanism to verify that secrets meet the following quality metric: the probability that a secret can be obtained by an attacker during the lifetime of the secret is less than 2^-20. FIA_SOS.1.1 Application Note: The TOE password change is implemented using the PAM library. The PAM module pam_passwdqc.so allows the specification of the quality of new passwords. The evaluated configuration requires a configuration of the PAM-based password change mechanism that meets the above mentioned criteria. Application Note: The Evaluated Configuration Guide contains configuration suggestions for the password quality mechanism that covers the above mentioned probability. These configuration suggestions assume the worst-case scenario when attacking these settings. Page 47 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Application Note: For key-based authentication methods, the evaluation of the RSA and DSA keys used for the SSH protocol will show the maximum lifetime of a key depending on its size. 6.1.1.33 Timing of authentication (FIA_UAU.1) The TSF shall allow FIA_UAU.1.1 a) the information flow covered by the Network Information Flow Control Policy; b) Local console log-in: banner information; c) SSH log-in: obtaining the list of allowed authentication methods; on behalf of the user to be performed before the user is authenticated. The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. FIA_UAU.1.2 6.1.1.34 Multiple authentication mechanisms (FIA_UAU.5) The TSF shall provide the following authentication mechanisms: FIA_UAU.5.1 a) Authentication based on username and password; b) Authentication based on software token verification data; c) No other authentication mechanisms to support user authentication. Application Note: The TOE is able to maintain the following types of software tokens and their verification data: ● SSH user keys: The TOE as server part is able to store the public part of the SSH user key for the user account the user wants to access. The TSF shall authenticate any user's claimed identity according to the following rules: FIA_UAU.5.2 a) Authentication based on username and password is performed for TOE-originated requests and credentials stored by the TSF; b) Authentication based on software token verification data is performed for TOE-originated requests; c) For SSH, both, the password-based and key-based authentication methods can be enabled at the same time. In this case, the key-based authentication method is tried before the password-based authentication. If the key-based authentication succeeds, the user is authenticated. If the key-based authentication fails, the password-based authentication is applied. If the password-based authentication fails, the user login request is denied. 6.1.1.35 Protected authentication feedback (FIA_UAU.7) The TSF shall provide only obscured feedback to the user while the authentication is in progress. FIA_UAU.7.1 6.1.1.36 Timing of identification (FIA_UID.1) The TSF shall allow FIA_UID.1.1 a) Console log-in: banner information; Page 48 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z b) SSH log-in: obtaining the list of allowed authentication methods; on behalf of the user to be performed before the user is identified. The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. FIA_UID.1.2 6.1.1.37 Enhanced user-subject binding (FIA_USB.2) The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: FIA_USB.2.1 a) The user identity that is associated with auditable events; b) The user security attributes that are used to enforce the Persistent Storage Object Access Control Policy; c) The user security attributes that are used to enforce the Transient Storage Object Access Control Policy; d) The software token that can be used for subsequent identification and authentication with the TSF or other remote IT systems; e) Active roles; f) Active groups; g) no other attributes. The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: FIA_USB.2.2 a) Upon successful identification and authentication, the login UID, the real UID, the filesystem UID and the effective UID shall be those specified in the user entry for the user that has authenticated successfully; b) Upon successful identification and authentication, the real GID, the filesystem GID and the effective GID shall be those specified via the primary group membership attribute in the user entry; c) Upon successful identification and authentication, the supplemental GIDs shall be those specified via the supplemental group membership assignment for the user entry; Application Note: The various subject UIDs are all derived from the same numeric UID per user entry stored in the /etc/passwd file. Application Note: The various subject GIDs except the supplemental GIDs are all derived from the same numeric GID per user entry stored in the /etc/passwd file. Application Note: The subject's supplemental GIDs are derived from the username to group name mappings in the /etc/group file. As the TOE only maintains numeric IDs for subjects, the username and the group names need to be converted before instantiating the subject. The username to UID mapping is provided in /etc/passwd and the group name to GID mapping is provided in /etc/group. The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: FIA_USB.2.3 a) The effective and filesystem UID of a subject can be changed by the use of an executable with the SETUID bit set. In this case the program is executed with the effective and filesystem UID of the owning UID of the file storing the program. These Page 49 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z newly set effective and filesystem UIDs are used for the DAC permission validation. The real and login UID remain unchanged. b) The effective and filesystem GID of a subject can be changed by the use of an executable with the SETGID bit set. In this case the program is executed with the effective and filesystem GID of the owning GID of the file storing the program. These newly set effective and filesystem GIDs are used for the DAC permission validation. The real GID remains unchanged. c) The real, effective and filesystem UID of a subject can be changed by the use of the set*uid system call family for the calling application. These system calls are restricted to processes possessing the CAP_SETUID capability. d) The real, effective and filesystem GID of a subject can be changed by the use of the set*gid system call family for the calling application. These system calls are restricted to processes possessing the CAP_SETUID capability. e) The set of supplemental GIDs of a subject can be changed by the use of the setgroups system call for the calling application. These system calls are restricted to processes possessing the CAP_SETUID capability. Application Note: The applications "su" and "sudo" allow the calling user to change the filesystem and effective UID either to root or to other users provided the authentication to "su" or "sudo" was successful. Both application uses the SETUID bit with the owning UID of root as well as the set*uid system calls to change to other UIDs before spawning a new shell or the given command. As both applications rest on the above mentioned mechanisms, they are not listed as a separate mechanism to modify the calling user's UIDs. Application Note: The login UID is set by the PAM modules by inserting the intended UID into the /proc//loginuid file. This file can be written to only by subjects executing with the effective UID of zero (root) and only for the calling process' own loginuid file. However, there is no application except the PAM modules which access that proc file which implies that the login UID remains unchanged after login when operating the TOE. Authorized administrators are not intended to access that proc file. The TSF shall enforce the following rules for the assignment of subject security attributes not derived from user security attributes when a subject is created: No rules. FIA_USB.2.4 6.1.1.38 Reliable time stamps (FPT_STM.1) The TSF shall be able to provide reliable time stamps. FPT_STM.1.1 6.1.1.39 Inter-TSF basic TSF data consistency (FPT_TDC.1(BA)) The TSF shall provide the capability to consistently interpret the following data types: FPT_TDC.1.1 a) Packet filter: protocol headers for the network protocols covered by the packet filter; when shared between the TSF and another trusted IT product. The TSF shall use the following interpretation rules: FPT_TDC.1.2 a) Packet filter: protocol headers specification provided in RFC 791 (IP), RFC 793 (TCP), RFC 768 (UDP), RFC 792 (ICMP); Page 50 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z when interpreting the TSF data from another trusted IT product. 6.1.1.40 TSF-initiated session locking (FTA_SSL.1) The TSF shall lock an interactive session to a human user maintained by the TSF after an administrator-configurable time interval of user inactivity by: FTA_SSL.1.1 a) clearing or overwriting TSF controlled display devices, making the current contents unreadable; b) disabling any activity of the user's TSF controlled access/TSF controlled display devices other than unlocking the session. Application Note: The management aspect of configuring the time interval is covered by FMT_MTD.1(SSL). The TSF shall require the following events to occur prior to unlocking the session: FTA_SSL.1.2 a) Successful re-authentication with the credentials of the user owning the session using password based authentication; b) No other events. 6.1.1.41 User-initiated locking (FTA_SSL.2) The TSF shall allow user-initiated locking of the user's own interactive session maintained by the TSF, by: FTA_SSL.2.1 a) clearing or overwriting TSF controlled display devices, making the current contents unreadable; b) disabling any activity of the user's TSF controlled data access/TSF controlled display devices other than unlocking the session. The TSF shall require the following events to occur prior to unlocking the session: FTA_SSL.2.2 a) Successful re-authentication with the credentials of the user owning the session using password based authentication; b) No other events. 6.1.1.42 Inter-TSF trusted channel (FTP_ITC.1) The TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification and disclosure using the following mechanisms: FTP_ITC.1.1 a) Cryptographically-protected communication channel using SSH; b) No other trusted communication channel. The TSF shall permit another trusted IT product to initiate communication via the trusted channel. FTP_ITC.1.2 The TSF shall initiate communication via the trusted channel for all security functions specified in the ST that interact with remote trusted IT systems no other conditions or functions. FTP_ITC.1.3 Page 51 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 6.1.2 Confidentiality protection of data at rest 6.1.2.1 Complete access control (FDP_ACC.2(CP)) The TSF shall enforce the Confidentiality Access Control Policy on FDP_ACC.2.1 a) Subjects: all subjects defined with the Security Policy Model b) Objects: i. Persistent Storage Objects of the following type: all file system objects defined with the Security Policy Model. and all operations among subjects and objects covered by the SFP. The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. FDP_ACC.2.2 6.1.2.2 Security attribute based access control (FDP_ACF.1(CP)) The TSF shall enforce the Confidentiality Access Control Policy to objects based on the following: FDP_ACF.1.1 a) Subject security attributes: none as all subjects maintained by the TOE are covered; b) Persistent storage object security attributes: all persistent storage objects located on the protected block device; c) Block device object security attributes: session key used to encrypt and decrypt and data processed on that block device; d) User security attributes: passphrase that protects the session key using the LUKS protection mechanism. Application Note: The SFR mentions two different object attributes that are relevant to the security policy. The first is the session key used to encrypt data stored on the block device. However, file system objects (which contain the information the user wants to protect) are only covered by the encryption, if they are stored on the encrypted block device. Therefore, the storage location of the file system objects is another object security attribute as it decides about the protection status of the object. The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: FDP_ACF.1.2 a) Access granting when TSF are active: Every user with access to the mount point of the encrypted block device is granted access when the encrypted block device is unlocked and mounted; b) Access granting when TSF are active: Every user not in the possession of the passphrase to unlock the encrypted block device is denied access to data stored on that block device; c) Access granting when TSF are inactive: Every user not in the possession of the passphrase to unlock the encrypted block device is denied access to data stored on that block device. Application Note: The TOE provides the dm_crypt mechanism as a block device encryption. When the session key for the encryption and decryption operation is provided to the kernel, the encrypted block device is unlocked. At this point, the contents - the file system - is accessible to the kernel and can be mounted. If the session key is locked, all data is encrypted on the block device with a symmetric of either Triple-DES or AES. Page 52 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: no explicit access authorization to any subject. FDP_ACF.1.3 Application Note: When the block device is unlocked and mounted, it behaves exactly the same way as any other mounted file system. Note that any file system specific access control mechanisms like permission bits, and ACLs are added to the protection mechanism. The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4 6.1.2.3 Confidentiality for data at rest (FDP_CDP.1(CP)) The TSF shall enforce the Confidentiality Access Control Policy to store user data at rest in containers controlled by the TSF in a manner protected from unauthorised disclosure. FDP_CDP.1.1 6.1.3 Management related functionality 6.1.3.1 Management of object security attributes (FMT_MSA.1(PSO)) The TSF shall enforce the Persistent Storage Object Access Control Policy to restrict the ability to modify, change_default the security attributes of the objects covered by the SFP to the owner of the object and users with processes granted the CAP_CHOWN, CAP_FOWNER, CAP_FSETID capabilities. FMT_MSA.1.1 6.1.3.2 Management of object security attributes (FMT_MSA.1(TSO)) The TSF shall enforce the Transient Storage Object Access Control Policy to restrict the ability to modify the security attributes of the objects covered by the SFP to the owner of the object and users with processes granted the CAP_FOWNER capability. FMT_MSA.1.1 6.1.3.3 Management of security attributes (FMT_MSA.1(CP)) The TSF shall enforce the Confidentiality Access Control Policy to restrict the ability to modify, transfer, delete the security attributes of the block device objects covered by the SFP to the owner of the object. FMT_MSA.1.1 Application Note: The SFR applies to the management of the session key that encrypts the data on the block device. Only the owner, i.e. the user that is in possession of the passphrase protecting the session, is able to modify the key, to transfer it (i.e. to protect it with an additional passphrase) or to delete the session key. 6.1.3.4 Static attribute initialisation (FMT_MSA.3(PSO)) The TSF shall enforce the Persistent Storage Object Access Control Policy to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.1 The TSF shall allow the FMT_MSA.3.2 a) root user for a global setting applied during logon; b) each user for a setting applicable to his processes; c) users with write permissions to a directory for setting default ACLs Page 53 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z to specify alternative initial values to override the default values when an object or information is created. Application Note: The global default value for permission bits is specified with the umask value which specifies the permission bits for newly created objects. This value has an initial setting of 022 or the value specified in /etc/login.defs. Only the root user can manage that initial value as this file is writeable to root only. Users can change their umask value at any time using the umask(2) system call. For ACLs, the default ACL is provided for for the root directory which, in case of absence of a default ACL entry is consistent with the umask. 6.1.3.5 Static attribute initialisation (FMT_MSA.3(TSO)) The TSF shall enforce the Transient Storage Object Access Control Policy to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.1 The TSF shall allow the FMT_MSA.3.2 a) root user for a global setting applied during logon; b) each user for a setting applicable to his processes to specify alternative initial values to override the default values when an object or information is created. Application Note: The global default value for permission bits is specified with the umask value which specifies the permission bits for newly created objects. This value has an initial setting of 022 or the value specified in /etc/login.defs. Only the root user can manage that initial value as this file is writeable to root only. Users can change their umask value at any time using the umask(2) system call. 6.1.3.6 Static attribute initialisation (FMT_MSA.3(NI)) The TSF shall enforce the Network Information Flow Control Policy to provide permissive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.1 The TSF shall allow the users with processes granted the CAP_NET_ADMIN capability to specify alternative initial values to override the default values when an object or information is created. FMT_MSA.3.2 Application Note: The default value specified in this SFR applies to the default for the packet filter after boot. The administrator can configure alternative default values as outlined in FDP_IFF.1(NI-IPTables) as well as FDP_IFF.1(NI-ebtables). Application Note: The iptables and ebtables commands use a netlink interfact to the kernel which requires that the caller possesses the CAP_NET_ADMIN capability. 6.1.3.7 Static attribute initialisation (FMT_MSA.3(CP)) The TSF shall enforce the Confidentiality Access Control Policy to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.1 The TSF shall allow nobody to specify alternative initial values to override the default values when an object or information is created. FMT_MSA.3.2 Application Note: Restrictive default values apply to the protection of the session key: the session key is created and immediately protected with a passphrase. Therefore, only the creator of the session key is initially able to access the locked block device. Page 54 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 6.1.3.8 Security attribute value inheritance (FMT_MSA.4(PSO)) The TSF shall use the following rules to set the value of security attributes for Persistent Storage Objects: FMT_MSA.4.1 a) The newly created object's owning UID is set to the effective UID of the calling subject; b) The newly created object's owning GID is set to the effective GID of the calling subject with the following exception for file system objects: if the parent directory holding the newly created file system object is marked with the SETGID permission bit, the owning GID of the newly created file system object is set to the owning GID of the parent directory; c) The newly created object's permission bits are derived from the calling subject's umask value by masking out the umask bits from the permission bit set granting full access; d) The newly created object's ACLs are derived from the default ACL specified for the parent directory the newly created file system object is stored in, if existant. Otherwise, no ACL is set. . 6.1.3.9 Management of TSF data (FMT_MTD.1(AE)) The TSF shall restrict the ability to query, modify the set of audited events to processes with the capability CAP_AUDIT_CONTROL. FMT_MTD.1.1 Application Note: This SFR applies to FAU_SEL.1. Application Note: Using the audit tools which in turn use the netlink interface, an administrator can configure the audit rules. 6.1.3.10 Management of TSF data (FMT_MTD.1(AS)) The TSF shall restrict the ability to clear delete, configure the storage location the audit storage to the root user. FMT_MTD.1.1 Application Note: This SFR applies to FAU_STG.1 where the directory used for storing the audit trail is configured. Application Note: The configuration of these parameters is performed with the configuration file /etc/auditd/auditd.conf which is writeable to the root user only. 6.1.3.11 Management of TSF data (FMT_MTD.1(AT)) The TSF shall restrict the ability to modify add, delete the FMT_MTD.1.1 a) threshold of the audit trail when an action is performed; b) action when the threshold is reached to the root user. Application Note: This SFR applies to FAU_STG.3. Application Note: The configuration of these parameters is performed with the configuration file /etc/auditd/auditd.conf which is writeable to the root user only. Page 55 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 6.1.3.12 Management of TSF data (FMT_MTD.1(AF)) The TSF shall restrict the ability to modify add, delete the actions to be taken in case of audit storage failure to the root user. FMT_MTD.1.1 Application Note: This SFR applies to FAU_STG.4. Application Note: The configuration of these parameters is performed with the configuration file /etc/auditd/auditd.conf which is writeable to the root user only. 6.1.3.13 Management of TSF data (FMT_MTD.1(NI)) The TSF shall restrict the ability to query, modify, delete change_default the security attributes for the rules governing the FMT_MTD.1.1 a) identification of network packets by the packet filter; b) actions performed on the identified network packets by the packet filter; to users with processes granted the CAP_NET_ADMIN capability. Application Note: This SFR applies to FDP_IFF.1(NI). Application Note: The iptables and ebtables commands use a netlink interfact to the kernel which requires that the caller possesses the CAP_NET_ADMIN capability. 6.1.3.14 Management of TSF data (FMT_MTD.1(IAT)) The TSF shall restrict the ability to modify the threshold for unsuccessful authentication attempts to the root user. FMT_MTD.1.1 Application Note: This SFR applies to FIA_AFL.1. Application Note: The configuration of these parameters is performed with the PAM configuration files which are writeable to the root user only. 6.1.3.15 Management of TSF data (FMT_MTD.1(IAF)) The TSF shall restrict the ability to re-enable the authentication to the account subject to authentication failure to the root user. FMT_MTD.1.1 Application Note: This SFR applies to FIA_AFL.1. Application Note: The account locking information is stored in the directory /var/log/faillock. Using the pam_faillock application which modifies this file, the account can be unlocked. The DAC permissions of that file ensure that only the root user can write to it. 6.1.3.16 Management of TSF data (FMT_MTD.1(IAU)) The TSF shall restrict the ability to initialize, modify, delete the user security attributes to FMT_MTD.1.1 a) the root user, b) users authorized to modify their own authentication data. Application Note: This SFR applies to FIA_ATD.1, FIA_UAU.1, and FIA_UID.1. Application Note: The configuration of these parameters is performed with the configuration files /etc/passwd and /etc/shadow which are writeable to the root user only. Page 56 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 6.1.3.17 Management of TSF data (FMT_MTD.1(SSH)) The TSF shall restrict the ability to modify the authentication methods provided by the OpenSSH server to the root user. FMT_MTD.1.1 Application Note: This SFR applies to FIA_UAU.5. Application Note: The configuration of this parameter is performed with the configuration file /etc/sshd_config which is writeable to the root user only. 6.1.3.18 Management of TSF data (FMT_MTD.1(SSL)) The TSF shall restrict the ability to modify the time interval of user inactivity for locking an interactive session to FMT_MTD.1.1 a) the root user for system wide settings, b) each user for his own sessions, if allowed by the root user. Application Note: This SFR applies to FTA.SSL.1. Application Note: The time interval is configured in /etc/screenrc which is writeable to root only. Normal users can configure the time interval in ~/.screenrc. The screen application enforcing the session locking can be configured to execute with /etc/profile or /etc/login.csh. The root user can place screen execution commands in these Shell startup files that prevent the loading of ~/.screenrc. 6.1.3.19 Management of TSF data (FMT_MTD.1(CP-AN)) The TSF shall restrict the ability to modify the confidentiality protection anchor to the owner of the dm-crypt partition . FMT_MTD.1.1 Application Note: The trust anchor is the passphrases that protect the master key for a dm-crypt partition. 6.1.3.20 Management of TSF data (FMT_MTD.1(CP-UD)) The TSF shall restrict the ability to enable, disable the security attributes governing the enforcement of the Confidentiality Access Control Polity on an object to the owner of the dm-crypt partition. FMT_MTD.1.1 6.1.3.21 Revocation (FMT_REV.1(OBJ)) The TSF shall restrict the ability to revoke object security attributes defined by SFPs associated with the corresponding object under the control of the TSF to FMT_REV.1.1 a) DAC permissions: owners of the object and authorized administrator; b) Other security attributes: authorized administrator. Application Note: The privileges that constitute an authorized administrator are defined in the above mentioned FMT_* SFRs which specify the privileges needed to modify object security attributes. The same privileges are required to revoke these security attributes. The TSF shall enforce the following rules: FMT_REV.1.2 a) The access rights associated with an object shall be enforced when an access check is made; b) no specification of other revocation rules. Page 57 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Application Note: Revocation of security attributes for named objects imply the revocation of access granted to users other than the owner of the object. Note that the DAC ownership management (which can be also considered as a form of access revocation) is specified in FMT_MSA.1(PSO). 6.1.3.22 Revocation (FMT_REV.1(USR)) The TSF shall restrict the ability to revoke user security attributes defined by the SFP associated with the corresponding user under the control of the TSF to authorized administrators. FMT_REV.1.1 Application Note: The privileges that constitute an authorized administrator are defined in the above mentioned FMT_* SFRs which specify the privileges needed to modify object security attributes. The same privileges are required to revoke these security attributes. The TSF shall enforce the following rules: FMT_REV.1.2 a) The enforcement of the revocation of security-relevant authorizations with the next user-subject binding process during the next authentication of the user; b) No other rules Application Note: The changes are enforced for a new session when the user affected by the change initiates that new session. 6.1.3.23 Specification of management functions (FMT_SMF.1) The TSF shall be capable of performing the following management functions: FMT_SMF.1.1 a) Management of auditing; b) Management of cryptographic network protocols; c) Management of Persistent Storage Object Access Control Policy; d) Management of Network Information Flow Control Policy; e) Management of identification and authentication policy; f) Management of user security attributes; g) no other functions; Application Note: The given list is kept intentionally generic. This ST specifies one iteration of FMT_MTD.1 per management function required by an SFR. For each FMT_MTD.1 iteration, a corresponding application note refers to the covered SFR(s). 6.1.3.24 Security management roles (FMT_SMR.1) The TSF shall maintain the roles: FMT_SMR.1.1 a) User role with the following rights: i. Users are authorized to modify their own user password; ii. Users are authorized to modify the access control permissions for the named objects they own; iii. no other rights; b) Configurations stored by user space: administrative users defined by the access permissions to the configurations mentioned in the other management SFRs; c) Functions provided by the kernel: administrative users defined by capabilities mentioned in other management SFRs; The TSF shall be able to associate users with roles. FMT_SMR.1.2 Page 58 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Application Note: Administrative actions can only be performed when the calling subject possesses the above mentioned capabilities which in the TOE configuration is only provided to processes executing with the effective UID or file system UID of zero (also called the root user). As the account for the root user is disabled for direct logon, authorized administrators are defined as users who are assigned to the "wheel" group. This group allows the use of the "su" application which is the only way to assume the root user capabilities. In addition, the "sudo" application allows granting users the privilege to execute commands with a different user ID, including the root user. 6.2 Security Functional Requirements Rationale 6.2.1 Coverage The following table provides a mapping of SFR to the security objectives, showing that each security functional requirement addresses at least one security objective. Objectives Security Functional Requirements O.AUDITING FAU_GEN.1 O.AUDITING FAU_GEN.2 O.AUDITING FAU_SAR.1 O.AUDITING FAU_SAR.2 O.AUDITING FAU_SEL.1 O.AUDITING FAU_STG.1 O.AUDITING FAU_STG.3 O.AUDITING FAU_STG.4 O.CRYPTO.NET FCS_CKM.1(SYM) O.CRYPTO.NET FCS_CKM.1(RSA) O.CRYPTO.NET FCS_CKM.1(DSA) O.CRYPTO.NET FCS_CKM.2(NET) O.CRYPTO.NET FCS_CKM.4 O.CRYPTO.NET FCS_COP.1(NET) O.CP.USERDATA FCS_COP.1(CP) O.CRYPTO.NET FCS_RNG.1(SSH-DFLT) O.CRYPTO.NET FCS_RNG.1(SSH-FIPS) O.CP.USERDATA FCS_RNG.1(DM) O.DISCRETIONARY .ACCESS FDP_ACC.1(PSO) O.SUBJECT.COM FDP_ACC.1(TSO) O.DISCRETIONARY .ACCESS FDP_ACF.1(PSO) O.SUBJECT.COM FDP_ACF.1(TSO) Page 59 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Objectives Security Functional Requirements O.NETWORK.FLOW FDP_IFC.2(NI) O.NETWORK.FLOW FDP_IFF.1(NI-IPTables) O.NETWORK.FLOW FDP_IFF.1(NI-ebtables) O.DISCRETIONARY .ACCESS, O.NETWORK.FLOW, O.SUBJECT.COM FDP_ITC.2(BA) O.AUDITING, O.CRYPTO.NET, O.DISCRETIONARY .ACCESS, O.I&A, O.NETWORK.FLOW, O.SUBJECT.COM FDP_RIP.2 O.AUDITING, O.CRYPTO.NET, O.DISCRETIONARY .ACCESS, O.I&A, O.NETWORK.FLOW, O.SUBJECT.COM FDP_RIP.3 O.I&A FIA_AFL.1 O.I&A FIA_ATD.1(HU) O.NETWORK.FLOW FIA_ATD.1(TU) O.I&A FIA_SOS.1 O.I&A FIA_UAU.1 O.I&A FIA_UAU.5 O.I&A FIA_UAU.7 O.I&A, O.NETWORK.FLOW FIA_UID.1 O.I&A FIA_USB.2 O.AUDITING FPT_STM.1 O.DISCRETIONARY .ACCESS, O.NETWORK.FLOW, O.SUBJECT.COM FPT_TDC.1(BA) O.I&A FTA_SSL.1 O.I&A FTA_SSL.2 O.TRUSTED_CHANNEL FTP_ITC.1 O.CP.USERDATA FDP_ACC.2(CP) O.CP.USERDATA FDP_ACF.1(CP) O.CP.USERDATA FDP_CDP.1(CP) Page 60 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Objectives Security Functional Requirements O.MANAGE FMT_MSA.1(PSO) O.MANAGE FMT_MSA.1(TSO) O.CP.USERDATA FMT_MSA.1(CP) O.MANAGE FMT_MSA.3(PSO) O.MANAGE FMT_MSA.3(TSO) O.MANAGE FMT_MSA.3(NI) O.CP.USERDATA FMT_MSA.3(CP) O.MANAGE FMT_MSA.4(PSO) O.MANAGE FMT_MTD.1(AE) O.MANAGE FMT_MTD.1(AS) O.MANAGE FMT_MTD.1(AT) O.MANAGE FMT_MTD.1(AF) O.MANAGE FMT_MTD.1(NI) O.MANAGE FMT_MTD.1(IAT) O.MANAGE FMT_MTD.1(IAF) O.MANAGE FMT_MTD.1(IAU) O.MANAGE FMT_MTD.1(SSH) O.MANAGE FMT_MTD.1(SSL) O.CP.ANCHOR FMT_MTD.1(CP-AN) O.CP.USERDATA FMT_MTD.1(CP-UD) O.MANAGE FMT_REV.1(OBJ) O.MANAGE FMT_REV.1(USR) O.MANAGE FMT_SMF.1 O.MANAGE FMT_SMR.1 Table 8: Mapping of security functional requirements to security objectives 6.2.2 Sufficiency The following rationale provides justification for each security objective for the TOE, showing that the security functional requirements are suitable to meet and achieve the security objectives: Page 61 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Rationale Security objectives The events to be audited are defined in [FAU_GEN.1] and are associated with the identity of the user that caused the event [FAU_GEN.2]. Authorized users are provided the capability to read the O.AUDITING audit records [FAU_SAR.1], while all other users are denied access to the audit records [FAU_SAR.2]. The authorized user must have the capability to specify which audit records are generated [FAU_SEL.1]. The TOE prevents the audit log from being modified or deleted [FAU_STG.1] and ensures that the audit log is not lost due to resource shortage [FAU_STG.3, FAU_STG.4]. To support auditing, the TOE is able to maintain proper time stamps [FPT_STM.1]. The protection of reused resources ensures that no data leaks from other protected sources [FDP_RIP.2, FDP_RIP.3]. The cryptographically-protected network protocol [FCS_COP.1(NET)] is supported by the generation of symmetric keys [FCS_CKM.1(SYM)], as well as asymmetric keys [FCS_CKM.1(RSA), FCS_CKM.1(DSA)] where O.CRYPTO.NET the functionality is based on the random number generator as defined by [FCS_RNG.1(SSH-DFLT), FCS_RNG.1(SSH-FIPS)]. As part of the cryptographic network protocol, the TOE securely exchanges the symmetric key with a remote trusted IT system [FCS_CKM.2(NET)]. The TOE ensures that all keys are zeroized upon de-allocation [FCS_CKM.4]. The protection of reused resources ensures that no data leaks from other protected sources [FDP_RIP.2, FDP_RIP.3]. The TSF must control access to resources based on the identity of users that are allowed to specify which resources they want to access for storing their data. O.DISCRETIONARY .ACCESS The access control policy must have a defined scope of control [FDP_ACC.1(PSO)]. The rules for the access control policy are defined [FDP_ACF.1(PSO)]. When import of user data is allowed, the TOE must ensure that user data security attributes required by the access control policy are correctly interpreted [FDP_ITC.2(BA), FPT_TDC.1(BA)]. The protection of reused resources ensures that no data leaks from other protected sources [FDP_RIP.2, FDP_RIP.3]. The network information flow control mechanism controls the information flowing between different entities [FDP_IFC.2(NI)]. The TOE implements a rule-set governing the information flow O.NETWORK.FLOW [FDP_IFF.1(NI-IPTables), FDP_IFF.1(NI-ebtables)]. To facilitate the information flow control, the information must be identified [FIA_UID.1] based on security attributes the TOE can maintain [FIA_ATD.1(TU)]. The TOE must ensure that security attributes of the network data required by the information flow control policy are correctly interpreted [FDP_ITC.2(BA), FPT_TDC.1(BA)]. The protection of reused resources ensures that no data leaks from other protected sources [FDP_RIP.2, FDP_RIP.3]. The TSF must control the exchange of data using transient storage objects between subjects based on the identity of users. O.SUBJECT.COM Page 62 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Rationale Security objectives The access control policy must have a defined scope of control [FDP_ACC.1(TSO)]. The rules for the access control policy are defined [FDP_ACF.1(TSO)]. When import of user data is allowed, the TOE must ensure that user data security attributes required by the access control policy are correctly interpreted [FDP_ITC.2(BA), FPT_TDC.1(BA)]. The protection of reused resources ensures that no data leaks from other protected sources [FDP_RIP.2, FDP_RIP.3]. The TSF must ensure that only authorized users gain access to the TOE and its resources. Users authorized to access the TOE must use an identification and authentication process [FIA_UID.1, FIA_UAU.1]. O.I&A Multiple I&A mechanisms are allowed as specified in [FIA_UAU.5]. To ensure authorized access to the TOE, authentication data is protected [FIA_ATD.1(HU), FIA_UAU.7]. Proper authorization for subjects acting on behalf of users is also ensured [FIA_USB.2]. The appropriate strength of the authentication mechanism is ensured [FIA_SOS.1]. To support the strength of authentication methods, the TOE is capable of identifying and reacting to unsuccessful authentication attempts [FIA_AFL.1]. In addition, user-initiated and TSF-initiated session locking [FTA_SSL.1, FTA_SSL.2] protect the authenticated user's session. The protection of reused resources ensures that no data leaks from other protected sources [FDP_RIP.2, FDP_RIP.3] are present. The TOE provides management interfaces globally defined in [FMT_SMF.1] for: O.MANAGE ● the access control policies [FMT_MSA.1(PSO), FMT_MSA.1(TSO), FMT_MSA.3(PSO), FMT_MSA.3(TSO)]; ● the information flow control policy [FMT_MSA.3(NI), FMT_MTD.1(NI)]; ● the auditing aspects [FMT_MTD.1(AE), FMT_MTD.1(AS), FMT_MTD.1(AT), FMT_MTD.1(AF)]; ● the identification and authentication aspects [FMT_MTD.1(IAT), FMT_MTD.1(IAF), FMT_MTD.1(IAU), FMT_MTD.1(SSH)]. ● the session locking threshold [FMT_MTD.1(SSL)]. Persistently stored user data is stored either in hierarchical or relational fashion, which implies an inheritance of security attributes from parent object [FMT_MSA.4(PSO)]. The rights management for the different management aspects is defined with [FMT_SMR.1]. The management interfaces for the revocation of user and object attributes is provided with [FMT_REV.1(OBJ) and FMT_REV.1(USR)]. The TOE provides a trusted channel protecting communication between a remote trusted IT system and itself [FTP_ITC.1]. O.TRUSTED_CHANNEL The confidentiality protection mechanism for user data at rest is provided with the access control policy specified with [FDP_ACC.2(CP)] and [FDP_ACF.1(CP)] and supported by the cryptographic operations defined in [FCS_COP.1(CP)]. In addition, the confidentiality mechanism is defined with [FDP_CDP.1(CP)]. O.CP.USERDATA Page 63 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Rationale Security objectives The the confidentiality protection is implemented with cryptographic mechanisms where the symmetric keys are derived from a random number generator as defined by [FCS_RNG.1(DM)]. The management of the confidentiality protection mechanism is covered by [FMT_MSA.1(CP)] and [FMT_MSA.3(CP)] covering the general management aspects. [FMT_MTD.1(CP-UD)] allows owners of user data to select which of their data is covered by the confidentiality protection mechanism. The management of the trust anchor for the confidentiality protection mechanism is specified with [FMT_MTD.1(CP-AN)]. O.CP.ANCHOR Table 9: Security objectives for the TOE rationale 6.2.3 Security requirements dependency analysis The following table demonstrates the dependencies of SFRs modeled in CC Part 2 and how the SFRs for the TOE resolve those dependencies: Resolution Dependencies Security Functional Requirement FPT_STM.1 FPT_STM.1 FAU_GEN.1 FAU_GEN.1 FAU_GEN.1 FAU_GEN.2 FIA_UID.1 FIA_UID.1 FAU_GEN.1 FAU_GEN.1 FAU_SAR.1 FAU_SAR.1 FAU_SAR.1 FAU_SAR.2 FAU_GEN.1 FAU_GEN.1 FAU_SEL.1 FMT_MTD.1(AE) FMT_MTD.1 FAU_GEN.1 FAU_GEN.1 FAU_STG.1 FAU_STG.1 FAU_STG.1 FAU_STG.3 FAU_STG.1 FAU_STG.1 FAU_STG.4 FCS_COP.1(NET) [FCS_CKM.2 or FCS_COP.1] FCS_CKM.1(SYM) FCS_CKM.4 FCS_CKM.4 FCS_COP.1(NET) [FCS_CKM.2 or FCS_COP.1] FCS_CKM.1(RSA) FCS_CKM.4 FCS_CKM.4 FCS_COP.1(NET) [FCS_CKM.2 or FCS_COP.1] FCS_CKM.1(DSA) FCS_CKM.4 FCS_CKM.4 Page 64 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Resolution Dependencies Security Functional Requirement FCS_CKM.1(SYM) FCS_CKM.1(RSA) FCS_CKM.1(DSA) [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.2(NET) FCS_CKM.4 FCS_CKM.4 FCS_CKM.1(SYM) [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_CKM.1(SYM) FCS_CKM.1(RSA) FCS_CKM.1(DSA) [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_COP.1(NET) FCS_CKM.4 FCS_CKM.4 FCS_CKM.1(SYM) [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_COP.1(CP) FCS_CKM.4 FCS_CKM.4 No dependencies. FCS_RNG.1(SSH- DFLT) No dependencies. FCS_RNG.1(SSH- FIPS) No dependencies. FCS_RNG.1(DM) FDP_ACF.1(PSO) FDP_ACF.1 FDP_ACC.1(PSO) FDP_ACF.1(TSO) FDP_ACF.1 FDP_ACC.1(TSO) FDP_ACC.1(PSO) FDP_ACC.1 FDP_ACF.1(PSO) FMT_MSA.3(PSO) FMT_MSA.3 FDP_ACC.1(TSO) FDP_ACC.1 FDP_ACF.1(TSO) FMT_MSA.3(TSO) FMT_MSA.3 FDP_IFF.1(NI-IPTables) FDP_IFF.1(NI-ebtables) FDP_IFF.1 FDP_IFC.2(NI) FDP_IFC.2(NI) FDP_IFC.1 FDP_IFF.1(NI-IPTa bles) FMT_MSA.3(NI) FMT_MSA.3 FDP_IFC.2(NI) FDP_IFC.1 FDP_IFF.1(NI-ebta bles) FMT_MSA.3(NI) FMT_MSA.3 FDP_ACC.1(PSO) FDP_ACC.1(TSO) FDP_IFC.2(NI) [FDP_ACC.1 or FDP_IFC.1] FDP_ITC.2(BA) FTP_ITC.1 [FTP_ITC.1 or FTP_TRP.1] FPT_TDC.1(BA) FPT_TDC.1 No dependencies. FDP_RIP.2 No dependencies. FDP_RIP.3 Page 65 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Resolution Dependencies Security Functional Requirement FIA_UAU.1 FIA_UAU.1 FIA_AFL.1 No dependencies. FIA_ATD.1(HU) No dependencies. FIA_ATD.1(TU) No dependencies. FIA_SOS.1 FIA_UID.1 FIA_UID.1 FIA_UAU.1 No dependencies. FIA_UAU.5 FIA_UAU.1 FIA_UAU.1 FIA_UAU.7 No dependencies. FIA_UID.1 FIA_ATD.1(HU) FIA_ATD.1 FIA_USB.2 No dependencies. FPT_STM.1 No dependencies. FPT_TDC.1(BA) FIA_UAU.1 FIA_UAU.1 FTA_SSL.1 FIA_UAU.1 FIA_UAU.1 FTA_SSL.2 No dependencies. FTP_ITC.1 FDP_ACF.1(CP) FDP_ACF.1 FDP_ACC.2(CP) FDP_ACC.2(CP) FDP_ACC.1 FDP_ACF.1(CP) FMT_MSA.3(CP) FMT_MSA.3 FDP_ACC.2(CP) [FDP_ACC.1 or FDP_IFC.1] FDP_CDP.1(CP) FDP_ACC.1(PSO) [FDP_ACC.1 or FDP_IFC.1] FMT_MSA.1(PSO) FMT_SMR.1 FMT_SMR.1 FMT_SMF.1 FMT_SMF.1 FDP_ACC.1(PSO) [FDP_ACC.1 or FDP_IFC.1] FMT_MSA.1(TSO) FMT_SMR.1 FMT_SMR.1 FMT_SMF.1 FMT_SMF.1 FDP_ACC.2(CP) [FDP_ACC.1 or FDP_IFC.1] FMT_MSA.1(CP) FMT_SMR.1 FMT_SMR.1 FMT_SMF.1 FMT_SMF.1 FMT_MSA.1(PSO) FMT_MSA.1 FMT_MSA.3(PSO) FMT_SMR.1 FMT_SMR.1 Page 66 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Resolution Dependencies Security Functional Requirement FMT_MSA.1(TSO) FMT_MSA.1 FMT_MSA.3(TSO) FMT_SMR.1 FMT_SMR.1 See OSPP rationale. FMT_MSA.1 FMT_MSA.3(NI) FMT_SMR.1 FMT_SMR.1 FMT_MSA.1(CP) FMT_MSA.1 FMT_MSA.3(CP) FMT_SMR.1 FMT_SMR.1 FDP_ACC.1(PSO) [FDP_ACC.1 or FDP_IFC.1] FMT_MSA.4(PSO) FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(AE) FMT_SMF.1 FMT_SMF.1 FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(AS) FMT_SMF.1 FMT_SMF.1 FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(AT) FMT_SMF.1 FMT_SMF.1 FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(AF) FMT_SMF.1 FMT_SMF.1 FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(NI) FMT_SMF.1 FMT_SMF.1 FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(IAT) FMT_SMF.1 FMT_SMF.1 FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(IAF) FMT_SMF.1 FMT_SMF.1 FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(IAU) FMT_SMF.1 FMT_SMF.1 FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(SSH) FMT_SMF.1 FMT_SMF.1 FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(SSL) FMT_SMF.1 FMT_SMF.1 FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(CP-AN) FMT_SMF.1 FMT_SMF.1 Page 67 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Resolution Dependencies Security Functional Requirement FMT_SMR.1 FMT_SMR.1 FMT_MTD.1(CP-UD) FMT_SMF.1 FMT_SMF.1 FMT_SMR.1 FMT_SMR.1 FMT_REV.1(OBJ) FMT_SMR.1 FMT_SMR.1 FMT_REV.1(USR) No dependencies. FMT_SMF.1 FIA_UID.1 FIA_UID.1 FMT_SMR.1 Table 10: TOE SFR dependency analysis 6.3 Security Assurance Requirements The security assurance requirements for the TOE are the Evaluation Assurance Level 4 components, augmented by ALC_FLR.3, as specified in [CC] part 3. No operations are applied to the assurance components apart from the operation to ASE_CCL.1 as defined in [OSPP]. The security assurance requirements for the TOE are the Evaluation Assurance Level 4 components as specified in [CC] part 3, augmented by ALC_FLR.3. The following table shows the Security assurance requirements, and the operations performed on the components according to CC part 3: iteration (Iter.), refinement (Ref.), assignment (Ass.) and selection (Sel.). Operations Source Security assurance requirement Security assurance class Sel. Ass. Ref. Iter. No No Yes No CC Part 3 ASE_CCL.1 Conformance claims ASE Security Target evaluation No No No No CC Part 3 ASE_INT.1 ST introduction No No No No CC Part 3 ASE_SPD.1 Security problem definition No No No No CC Part 3 ASE_OBJ.2 Security objectives No No No No CC Part 3 ASE_ECD.1 Extended components definition No No No No CC Part 3 ASE_REQ.2 Derived security requirements No No No No CC Part 3 ASE_TSS.1 TOE summary specification No No No No CC Part 3 ADV_ARC.1 Security architecture description ADV Development No No No No CC Part 3 ADV_FSP.4 Complete functional specification No No No No CC Part 3 ADV_IMP.1 Implementation representation of the TSF No No No No CC Part 3 ADV_TDS.3 Basic modular design No No No No CC Part 3 AGD_OPE.1 Operational user guidance AGD Guidance documents No No No No CC Part 3 AGD_PRE.1 Preparative procedures Page 68 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Operations Source Security assurance requirement Security assurance class Sel. Ass. Ref. Iter. No No No No CC Part 3 ALC_CMC.4 Production support, acceptance pro cedures and automation ALC Life-cycle support No No No No CC Part 3 ALC_CMS.4 Problem tracking CM coverage No No No No CC Part 3 ALC_DEL.1 Delivery procedures No No No No CC Part 3 ALC_DVS.1 Identification of security measures No No No No CC Part 3 ALC_FLR.3 Systematic flaw remediation No No No No CC Part 3 ALC_LCD.1 Developer defined life-cycle model No No No No CC Part 3 ALC_TAT.1 Well-defined development tools No No No No CC Part 3 ATE_COV.2 Analysis of coverage ATE Tests No No No No CC Part 3 ATE_DPT.1 Testing: basic design No No No No CC Part 3 ATE_FUN.1 Functional testing No No No No CC Part 3 ATE_IND.2 Independent testing - sample No No No No CC Part 3 AVA_VAN.3 Focused vulnerability analysis AVA Vulnerability assessment Table 11: Security assurance requirements 6.3.1 Security Target evaluation (ASE) 6.3.1.1 Conformance claims (ASE_CCL.1) Developer action elements: The developer shall provide a conformance claim. ASE_CCL.1.1D The developer shall provide a conformance claim rationale. ASE_CCL.1.2D Content and presentation elements: The conformance claim shall contain a CC conformance claim that identifies the version of the CC to which the ST and the TOE claim conformance. ASE_CCL.1.1C The CC conformance claim shallshould describe the conformance of the ST to CC Part 2 as either CC Part 2 conformant or CC Part 2 extended. ASE_CCL.1.2C The CC conformance claim shall describe the conformance of the ST to CC Part 3 as either CC Part 3 conformant or CC Part 3 extended. ASE_CCL.1.3C The CC conformance claim shall be consistent with the extended components definition. ASE_CCL.1.4C The conformance claim shall identify all PPs and security requirement packages to which the ST claims conformance. ASE_CCL.1.5C Page 69 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z The conformance claim shall describe any conformance of the ST to a package as either package-conformant or package-augmented. ASE_CCL.1.6C The conformance claim rationale shall demonstrate that the TOE type is consistent with the TOE type in the PPs for which conformance is being claimed. ASE_CCL.1.7C The conformance claim rationale shall demonstrate that the statement of the security problem definition is consistent with the statement of the security problem definition in the PPs for which conformance is being claimed. ASE_CCL.1.8C The conformance claim rationale shall demonstrate that the statement of security objectives is consistent with the statement of security objectives in the PPs for which conformance is being claimed. ASE_CCL.1.9C The conformance claim rationale shall demonstrate that the statement of security requirements is consistent with the statement of security requirements in the PPs including the statements marked as "ST-Author Note"and the specification given in section 8.1 of the OSPP base for which conformance is being claimed. ASE_CCL.1.10C Evaluator action elements: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ASE_CCL.1.1E 6.4 Security Assurance Requirements Rationale The basis for the justification of EAL4 augmented with ALC_FLR.3 is the threat environment experienced by the typical consumers of the TOE. This matches the package description for EAL4 (enhanced-basic). Page 70 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 7 TOE Summary Specification 7.1 TOE Security Functionality The following section explains how the security functions are implemented. The different TOE security functions cover the various SFR classes. The primary security features of the TOE are: ● Audit ● Cryptographically secured communication channels ● Packet filter ● Identification and Authentication ● Discretionary Access Control ● Confidentiality protected data storage ● Security Management 7.1.1 Audit The Lightweight Audit Framework (LAF) is designed to be an audit system for Linux compliant with the requirements from Common Criteria. LAF is able to intercept all system calls as well as retrieving audit log entries from privileged user space applications. The subsystem allows configuring the events to be actually audited from the set of all events that are possible to be audited. Those events are configured in a specific configuration file and then the kernel is notified to build its own internal structure for the events to be audited. 7.1.1.1 Audit functionality The Linux kernel implements the core of the LAF functionality. It gathers all audit events, analyzes these events based on the audit rules and forwards the audit events that are requested to be audited to the audit daemon executing in user space. Audit events are generated in various places of the kernel. In addition, a user space application can create audit records which needs to be fed to the kernel for further processing. The audit functionality of the Linux kernel is configured by user space applications which communicate with the kernel using a specific netlink communication channel. This netlink channel is also to be used by applications that want to send an audit event to the kernel. The kernel netlink interface is usable only by applications possessing the following capabilities: ● CAP_AUDIT_CONTROL: Performing management operations like adding or deleting audit rules, setting or getting auditing parameters; ● CAP_AUDIT_WRITE: Submitting audit records to the kernel which in turn forwards the audit records to the audit daemon. Based on the audit rules, the kernel decides whether an audit event is discarded or to be sent to the user space audit daemon for storing it in the audit trail. The kernel sends the message to the audit daemon again using the above mentioned netlink communication channel. The audit daemon writes the audit records to the audit trail. An internal queuing mechanism is used for this purpose. When the queue does not have sufficient space to hold an audit record the TOE switches into single user mode, is halted or the audit daemon executes an administrator-specified notification action depending on the configuration of the audit daemon. This ensures that audit records do not get lost due to resource shortage and the administrator can backup and clear the audit trail to free disk space for new audit logs. Page 71 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Access to audit data by normal users is prohibited by the discretionary access control function of the TOE, which is used to restrict the access to the audit trail and audit configuration files to the system administrator only. The system administrator can define the events to be audited from the overall events that the Lightweight Audit Framework using simple filter expressions. This allows for a flexible definition of the events to be audited and the conditions under which events are audited. The system administrator is also able to define a set of user IDs for which auditing is active or alternatively a set of user IDs that are not audited. The system administrator can select files to be audited by adding them to a watch list that is loaded into the kernel. This security function covers the SFRs of: FAU_GEN.1, FAU_GEN.2, FAU_SAR.2, FAU_SEL.1, FAU_STG.1, FAU_STG.3, FAU_STG.4, FPT_STM.1. 7.1.1.2 Audit trail An audit record consists of one or more lines of text containing fields in a “keyword=value” tagged format. The following information is contained in all audit record lines: ● Type: indicates the source of the event, such as SYSCALL, PATH, USER_LOGIN, or LOGIN ● Timestamp: Date and time the audit record was generated ● Audit ID: unique numerical event identifier ● Login ID (“auid”), the user ID of the user authenticated by the system (regardless if the user has changed his real and / or effective user ID afterwards) ● Effective user ID: the effective user ID of the process at the time the audit event was generated ● Success or failure (where appropriate) ● Process ID of the subject that caused the event (PID) This information is followed by event specific data. In some cases, such as SYSCALL event records involving file system objects, multiple text lines will be generated for a single event, these all have the same time stamp and audit ID to permit easy correlation. The audit trail is stored in ASCII text. The TOE provides tools for managing ASCII files that can be used for post-processing of audit data. These tools include: ● less - reads the ASCII audit data ● ausearch - allows selective extraction of records from the audit trail using defined selection criteria ● sort - The audit records are listed in chronological order by default. The sort utility can be used together with ausearch to use a different sorting order. The audit trail is stored in files which are accessible by root only. This security function covers the SFRs of: FAU_SAR.1. 7.1.2 Cryptographic services The TOE provides cryptographically secured network communication channels to allow remote users to interact with the TOE. Using one of the following cryptographically secured network channels, a user can request the following services: ● OpenSSH: The OpenSSH application provides access to the command line interface of the TOE. Users may employ OpenSSH for interactive sessions as well as for non-interactive sessions. The console provided via OpenSSH provides the same environment as a local console. OpenSSH implements the SSHv2 protocol. Page 72 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z In addition to the cryptographically secured communication channels, the TOE also provides cryptographic algorithms for general use. The cryptographic primitives for implementing the above mentioned cryptographic communication protocols are provided by OpenSSL. 7.1.2.1 SSHv2 Protocol The TOE provides the Secure Shell Protocol Version 2 (SSH v2.0) to allow users from a remote host to establish a secure connection and perform a logon to the TOE. The following table documents implementation details concerning the OpenSSH implementation’s compliance to the relevant standards. It addresses areas where the standards permit different implementation choices such as optional features. Implementation Details Description Reference The OpenSSH implementation is capable of interoperating with clients and servers using the old 1.x protocol. That functionality is explicitly disabled in the evaluated configuration, it permits protocol version 2.0 exclusively. Compatibility with old SSH versions RFC 4253 chapter 5 OpenSSH supports the OPTIONAL "zlib" compression method. Compression RFC 4253 section 6.2 The ciphers supported in the evaluated configuration are listed in FCS_COP.1(NET) for the SSH protocol. Encryption RFC 4253 section 6.3 This REQUIRED authentication method is supported by OpenSSH but can be disabled by the administrator of the OpenSSH daemon. Public Key Authentication Method: "publickey" RFC 4252 chapter 7 This SHOULD authentication method is supported by OpenSSH but can be disabled by the administrator of the OpenSSH daemon. Password Authentication Method: "password" RFC 4252 chapter 8 The OpenSSH implementation supports the optional password change mechanism in the evaluated configuration. Password change request and setting new password RFC 4252 chapter 8 This OPTIONAL authentication method is disabled in the evaluated configuration. Host-Based Authentication: "hostbased" RFC 4252 chapter 9 Table 12: SSH implementation notes The TOE supports the generation of RSA and DSA key pairs. These key pairs are used by OpenSSH for the host keys as well as for the per-user keys. When a user registers his public key with the user he wants to access on the server side, a key-based authentication can be performed instead of a password-based authentication. The key generation mechanism uses the Linux kernel random number generator. The evaluated configuration permits the import of externally-generated RSA/DSA key pairs. This security function covers the SFRs of: FCS_CKM.1(RSA), FCS_CKM.1(DSA). The TOE supports the following security functions of the SSH v2.0 protocol: ● Establishing a secure communication channel using the following cryptographic functions provided by the SSH v2.0 protocol: ❍ Encryption as defined in section 4.3 of RFC 4253 - the keys are generated using the Linux kernel random number generator; ❍ Diffie-Hellman key exchange as defined in section 6.1 of RFC 4253; Page 73 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z ❍ The keyed hash function for integrity protection as defined in section 4.4 of RFC 4253. Note: The protocol supports more cryptographic algorithms than the ones listed above. Those other algorithms are not covered by this evaluation and should be disabled or not used when running the evaluated configuration. ● Performing user authentication using the standard password-based authentication method the TOE provides for users (password authentication method as defined in chapter 5 of RFC 4252). ● Performing user authentication using a RSA or DSA key-based authentication method (public key authentication method as defined in chapter 5 of RFC 4252). ● Checking the integrity of the messages exchanged and close down the connection in case an integrity error is detected. The OpenSSH applications of sshd, ssh and ssh-keygen use the OpenSSL random number generator seeded by /dev/random to generate cryptographic keys. OpenSSL provides different DRNGs depending whether the FIPS 140-2 mode is enabled in the system. This security function covers the SFRs of: FCS_CKM.1(SYM), FCS_CKM.2(NET), FCS_CKM.4, FCS_COP.1(NET), FCS_RNG.1(SSH-DFLT), FCS_RNG.1(SSH-FIPS), FTP_ITC.1. 7.1.3 Packet filter The Linux kernel's network stack implementation follows the layering structure of the network protocols. It implements the code for handling the link layer as well as the network layer. For those layers, independent filter mechanism are provided: ● Link layer: ebtables implements the filtering mechanism for bridges ● Network layer: netfilter/iptables implements the filtering mechanism for non-bridge interfaces 7.1.3.1 Network layer filtering Netfilter Netfilter is a framework for packet mangling, implemented in the Linux kernel network stack handling the network layer. The netfilter framework comprises of the following parts: ● The IP stack defines five hooks which are well-defined points in a network packet's traversal of the IP protocol stack. Each of the hooks, the network stack will call the netfilter framework allowing it to operate on the entire packet. Note: the netfilter framework provides such hooks in a number of network protocol implementations, but the TOE only supports IP as outlined above. Therefore, the ST specification only covers the IP protocol. ● The netfilter framework provides register functions for other kernel parts to listen to the different hooks. When a packet traverses one of the hooks and passed to the netfilter framework, it invokes every registered kernel part. These kernel parts then can examine the packet and possible alter it. As part of the examination, these kernel parts can instruct the netfilter framework to discard the packet, to allow it to pass, or to queue it to user space. ● When a packet is marked to be queued to user space, the netfilter framework handles the asynchronous communication with user space. The netfilter framework implements the five hooks at the following points in the packet traversal chain: Page 74 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z ● When the packet enters the network layer of the TOE and after applying some sanity checks, but before the routing table is consulted, the NF_IP_PRE_ROUTING hook is triggered. ● After passing the routing table decision and the routing code marks the packet to be targeted for another host, the NF_IP_FORWARD hook is triggered. ● After passing the routing table decision and the routing code marks the packet to be targeted for the local system, the NF_IP_LOCAL_IN hook is triggered. ● When the packet traversed all of the network stack and is about to be placed on the wire again, the NF_IP_POST_ROUTING hook is triggered. ● When a packet is generated locally, the NF_IP_LOCAL_OUT hook is triggered before the routing table is consulted. IPTables All communication on the network layer can be controlled by the IPTables framework. The TOE implements a packet filter as part of the network stack provided with the Linux kernel. The combination of IPTables and netfilter implements the packet filter which provides stateful and stateless packet filtering for network communication by inspecting the IP header, the TCP header, UDP header and/or ICMP header of every network packet that passes the network stack. The packet selection system called IP Tables uses the netfilter framework to implement the actual packet filtering logic on the network layer for the TCP/IP protocol family. Note: IPTables is able to perform Network Address Translation (NAT) as well as Port Address Translation (PAT) for simple as well as more complex protocols. This mechanism is out of scope for the evaluation. Furthermore, packet mangling support is provided with IPTables which is also out of scope for the evaluation. IPTables registers all hooks provided by the netfilter framework. The NAT/PAT mechanism uses the pre-routing and post-routing hooks whereas the packet filtering capability is enforced on the local-in, local-out and forwaring hooks. IPTables consists of the following two components: ● In-kernel packet filter enforcement: The kernel-side of IPTables use the netfilter framework as indicated above. Three lists of packet filter rules are enforced by the kernel mechanism: one for each netfilter framework hook that applies to packet filtering. When a packet is analyzed by the IPTables kernel modules, they first select the applicable list based on the hook where the netfilter framework triggered IPTables. Each list contains zero or more rules which are iterated sequentially. A rule consists of a matching part (also called the "match extension") and an action part (also called the "target extension"). When a rule is applied to a packet, the kernel modules first applies the matching part of the rule. If the packet matches, the action part is enforced. If the action part contains a decision of the fate of the packet (to accept it, to drop it, or to drop it and sending a notification to the sender), the rule list validation stops for this packet. If the action part contains a modification instruction or log instruction for the packet, the rule list validation continues after performing this operation. When the rule list is iterated through and a packet could not be matched by a rule with a decision action (accept, drop), the default decision action applicable to the list is enforced. This default action is either to accept the packet, to drop the packet, or to drop the packet and send a notification to the sender. ● User space configuration application: The user space application iptables(1) allows the configuration of the IPTables kernel components. The application allows the specification of one rule per invocation where a rule contains the above mentioned matching part and action part. The tool also allows modification or deletion of existing rules as well as Page 75 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z configuration of the default action. When using the tool, each invocation must specify the netfilter framework hook to which the rule applies to. See the man page of iptables(1) for more details. 7.1.3.2 Link layer filtering ebtables chains Similarly to the netfilter hooks in the network layer handling protocol, the link layer code handling the bridging functionality implements chains that are used by ebtables to apply filtering. The netfilter framework is used to implement the ebtables chains at the following points in the packet traversal logic: ● When the packet enters the link layer of the TOE and after applying some sanity checks, but before the bridging decision made, the BROUTING chain is triggered. ● After passing the BROUTING chain but still before the bridging decision, the PREROUTING chain is triggered. When the bridging code decides that the frame is not intended for a bridge, it is forwarded to the network layer and processing on the link layer stops. ● After passing the bridge routing decision and the routing code marks the packet to be targeted for another host, the FORWARD chain is triggered. ● After passing the bridge routing decision and the routing code marks the packet to be targeted for the local system, the INPUT chain is triggered. ● When a packet is generated locally and the bridging decision marks the frame to be intended for a bridge, the OUTPUT chain is triggered. ● When the packet traversed all of the bridge logic and is about to be placed on the wire again, the POSTROUTING chain is triggered. ebtables filtering rules The packet selection system called ebtables uses the netfilter framework to implement the actual packet filtering logic for Ethernet frames routed through bridges. Bridged networking communication is only visible on the link layer. The data encapsulated within the Ethernet frames are not routed through the host system's network stack and can therefore not be analyzed and controlled by the IPTables framework outlined above. Even though the network stack of the host system does not analyze the bridged Ethernet frames any more, the ebtables framework receives the entire frame and is allowed to operate on that frame. Therefore, ebtables can analyze the protocol inside the Ethernet frame. Please note that the ST author is perfectly aware that the term "packet" is used for the network layer (which includes the TCP/IP protocol family), whereas the term "frame" applies to the link layer (which includes the Ethernet frames). However, when speaking about ebtables that can analyze IP packets inside the link layer, this ST refers to them as packets/frames. The ebtables framework can apply filters based on the following concepts: ● Matching of the frame/packet: Matches are based on Ethernet protocols or source and/or destination MAC addresses. ● Action to be performed on matched frames: Similarly to IPTables, ebtables must be configured to perform an action on the matched frame. The action can either be to discard the packet or to accept it. This security function covers the SFRs of: ● Packet filtering rules: FDP_IFC.2(NI), FDP_IFF.1(NI-*) ● Interpretation of network protocol: FIA_UID.1, FDP_ITC.2, FPT_TDC.1(BA) Page 76 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z ● Maintenance of rules: FIA_ATD.1(TU) 7.1.4 Identification and Authentication User identification and authentication in the TOE includes all forms of interactive login (e.g. using the SSH protocol or log in at the local console) as well as identity changes through the su and sudo commands. These all rely on explicit authentication information provided interactively by a user. In addition, the key-based authentication mechanism of the OpenSSH server is another form of of authentication. 7.1.4.1 PAM-based identification and authentication mechanisms Linux uses a suite of libraries called the "Pluggable Authentication Modules" (PAM) that allow an administrative user to choose how PAM-aware applications authenticate users. The TOE provides PAM modules that implement all the security functionality to: ● Provides login control and establishing all UIDs, GIDs and login ID for a subject ● Ensure the quality of passwords ● Enforce limits for accounts (such as the number of maximum concurrent sessions allowed for a user) ● Enforce the change of passwords after a configured time including the password quality enforcement ● Enforcement of locking of accounts after failed login attempts. ● Restriction of the use of the root account to certain terminals ● Restriction of the use of the su and sudo commands The login processing sets the real, file system effective and login UID as well as the real, effective, file system GID and the set of supplemental GIDs of the subject that is created. It is of course up to the client application usually provided by a remote system to protect the user’s entry of a password correctly (e. g. provide only obscured feedback). During login processing, the user is shown a banner. After successful authentication, the login time is recorded. After a successful identification and authentication, the TOE initiates a session for the user and spawns the initial login shell as the first process the user can interact with. The TOE provides a mechanism to lock a session either automatically after a configurable period of inactivity for that session or upon the user's request. This security function covers the SFRs of FDP_RIP.3, FIA_AFL.1, FIA_SOS.1, FIA_UAU.1, FIA_UID.1, FIA_UAU.5, FIA_UAU.7, FIA_USB.2. 7.1.4.2 User Identity Changing Users can change their identity (i.e., switch to another identity) using one of the following commands provided with the TOE: Page 77 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z su command The su command is intended for a switch to a another identity that establishes a new login session and spawns a new shell with the new identity. When invoking su, the user must provide the credentials associated with the target identity - i.e. when the user wants to switch to another user ID, it has to provide the password protecting the account of the target user. The primary use of the su command within the TOE is to allow appropriately authorized individuals the ability to assume the root identity to perform administrative actions. In this system the capability to login as the root identity has been restricted to defined terminals only. In addition the use of the su command to switch to root has been restricted to users belonging to a special group. Users that don’t have access to a terminal where root login is allowed and are not member of that special group will not be able to switch their real, file system and effective user ID to root even if they would know the authentication information for root. Note that when a user executes a program that has the setuid bit set, only the effective user ID and file system ID are changed to that of the owner of the file containing the program while the real user ID remains that of the caller. The login ID is neither changed by the su command nor by executing a program that has the setuid or setgid bit set as it is used for auditing purposes. sudo command The sudo command is intended for giving users permissions to execute commands with another user identity. When invoking sudo, the user has to authenticate with this credentials. Sudo is associated with sophisticated ruleset that can be engaged to specify which: ● source user ID ● originating from which host ● can access a command, a command with specific configuration flags, or all commands within a directory ● with which new user identity. When switching identities, the real, file system, and effective user ID, and real, file system, and effective group ID are changed to the one of the user specified in the command (after successful authentication as this user). Note: The login ID is not retained for the following special case: 1. User A logs into the system. 2. User A uses su to change to user B. 3. User B now edits the cron or at job queue to add new jobs. This operation is appropriately audited with the proper login ID. 4. Now when the new jobs are executed as user B, the system does not provide the audit information that the jobs are created by user A. The su command invokes the common authentication mechanism to validate the supplied authentication. This security function covers the SFRs of FIA_USB.2. 7.1.4.3 Authentication Data Management Each TOE instance maintains its own set of users with their passwords and attributes. Although the same human user may have accounts on different servers interconnected by a network and running an instantiation of the TOE, those accounts and their parameter are not synchronized on different TOE instances. As a result the same user may have different user names, different Page 78 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z user Ids, different passwords and different attributes on different machines within the networked environment. Existing mechanism for synchronizing this within the whole networked system are not subject to this evaluation. Each TOE instance within the network maintains its own administrative database by making all administrative changes on the local TOE instance. System administration has to ensure that all machines within the network are configured in accordance with the requirements defined in this Security Target. The file /etc/passwd contains for each user the user’s name, the id of the user, an indicator whether the password of the user is valid, the principal group id of the user and other (not security relevant) information. The file /etc/shadow contains for each user a hash of the user's password, the userid, the time the password was last changed, the expiration time as well as the validity period of the password and some other information that are not subject to the security functions as defined in this Security Target. Users are allowed to change their passwords by using the passwd command. This application is able to read and modify the contents of /etc/shadow for the user’s password entry, which would ordinarily be inaccessible to a non-privileged user process. Users are also warned to change their passwords at login time if the password will expire soon, and are prevented from logging in if the password has expired. The time of the last successful logins is recorded in the directory /var/log/tallylog where one file per user is kept. The TOE displays informative banners before or during the login to users. The banners can be specified with the files /etc/issue for log ins via the physical console or /etc/issue.net for remote log ins, such as via SSH. When performing a log in on the physical console, the banner is displayed above the username and password prompt. For log ins via SSH, the banner is displayed to the remote peer during the SSH-session handshake takes place. The remote SSH client will display the banner to the user. When using the provided OpenSSH client, the banner is displayed when the user instructs the OpenSSH client to log into the remote system. This security function covers the SFRs of FIA_ATD.1(HU). 7.1.4.4 SSH key-based authentication In addition to the PAM-based authentication outlined above, the OpenSSH server is able to perform a key-based authentication. When a user wants to log on, instead of providing a password, the user applies his SSH key. After a successful verification, the OpenSSH server considers the user as authenticated and performs the PAM-based operations as outlined above. To establish a key-based authentication, a user first has to generate an RSA or DSA key pair. The private part of the key pair remains on the client side. The public part is copied to the server into the file .ssh/authorized_keys which resides in the home directory of the user he wants to log on as. When the login operation is performed the SSHv2 protocol tries to perform the "publickey" authentication using the private key on the client side and the public key found on the server side. The operations performed during the publickey authentication is defined in RFC 4252 chapter 7. Users have to protect their private key part the same way as protecting a password. Appropriate permission settings on the file holding the private key is necessary. To strengthen the protection of the private key, the user can encrypt the key where a password serves as key for the encryption operation. See ssh-keygen(1) for more information. This security function covers the SFRs of FIA_UAU.1, FIA_UID.1, FIA_UAU.5, FIA_SOS.1. 7.1.4.5 Session locking The TOE uses the screen(1) application which locks the current session of the user either after an administrator-specified time of inactivity or upon the user's request. Page 79 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z To unlock the session, the user must supply his password. Screen uses PAM to validate the password and allows the user to access his session after a successful validation. This security function covers the SFRs of FTA_SSL.1, FTA_SSL.2. 7.1.5 Discretionary Access Control The general policy enforced is that subjects (i.e., processes) are allowed only the accesses specified by the policies applicable to the object the subject requests access to. Further, the ability to propagate access permissions is limited to those subjects who have that permission, as determined by the policies applicable to the object the subject requests access to. A subject may possess one or more of the following capabilities which provide the following exemptions from the DAC mechanism: ● CAP_DAC_OVERRIDE: A process with this capability is exempt from all restrictions of the discretionary access control and can perform any action desired. For the execution of a file, the permission bit vector of that file must contain at least one execute bit. ● CAP_DAC_READ_SEARCH: A process with this capability overrides all DAC restrictions regarding read and search on files and directories. ● CAP_CHOWN: A process with this capability is allowed to make arbitrary changes to a file's UID or GID. ● CAP_FOWNER: Setting permissions and ownership on objects even if the process' UID does not match the UID of the object. ● CAP_FSETID: Don't clear SUID and SGID permission bits when a file is modified. DAC provides the mechanism that allows users to specify and control access to objects that they own. DAC attributes are assigned to objects at creation time and remain in effect until the object is destroyed or the object attributes are changed. DAC attributes exist for, and are particular to, each type of named object known to the TOE. DAC is implemented with permission bits and, when specified, ACLs. The outlined DAC mechanism applies only to named objects which can be used to store or transmit user data. Other named objects are also covered by the DAC mechanism but may be supplemented by further restrictions. These additional restrictions are out of scope for this evaluation. Examples of objects which are accessible to users that cannot be used to store or transmit user data are: virtual file systems externalizing kernel data structures (such as most of procfs, sysfs, binfmt_misc) and process signals. During creation of objects, the TSF ensures that all residual contents is removed from that object before making it accessible to the subject requesting the creation. When data is imported into the TOE (such as when mounting disks created by other trusted systems), the TOE enforces the permission bits and ACLs applied to the file system objects. 7.1.5.1 Permission bits The TOE supports standard UNIX permission bits to provide one form of DAC for file system objects in all supported file systems. There are three sets of three bits that define access for three categories of users: the owning user, users in the owning group, and other users. The three bits in each set indicate the access permissions granted to each user category: one bit for read (r), one for write (w) and one for execute (x). Note that write access to file systems mounted as read only (e. g. CD-ROM) is always rejected (the exceptions are character and block device files which can still be written to as write operations do not modify the information on the storage media). Also, write access to file system objects marked as immutable is always rejected. The SAVETXT attribute is used for world-writeable temp directories preventing the removal of files by users other than the owner. Page 80 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Each process has an inheritable “umask” attribute which is used to determine the default access permissions for new objects. It is a bit mask of the user/group/other read/write/execute bits, and specifies the access bits to be removed from new objects. For example, setting the umask to “002” ensures that new objects will be writable by the owner and group, but not by others. The umask is defined by the administrator in the /etc/login.defs file or 022 by default if not specified. When using the VFAT file system at the /boot/efi mount point, the permissions applicable for every file system object beneath that mount point is specified with mount options. The mount system call allows the specification of the owning ID, group ID and the permissions applicable to the file system objects. The permissions specified at the mount point have the same semantics as the Unix permission bits. This security function covers the SFRs of FDP_ACC.1(PSO), FDP_ACF.1(PSO), FDP_ITC.1(BA), FDP_RIP.2, FPT_TDC.1(BA). 7.1.5.2 Access Control Lists (ACLs) The TOE provides support for POSIX type ACLs to define a fine grained access control on a user basis. ACLs are supported for all file system objects stored with the following file systems: ● btrfs ● ext3 ● xfs ● tmpfs An ACL entry contains the following information: ● A tag type that specifies the type of the ACL entry ● A qualifier that specifies an instance of an ACL entry type ● A permission set that specifies the discretionary access rights for processes identified by the tag type and qualifier An ACL contains exactly one entry of three different tag types (called the "required ACL entries” forming the "minimum ACL"). The standard UNIX file permission bits as described in the previous section are represented by the entries in the minimum ACL. A default ACL is an additional ACL which may be associated with a directory. This default ACL has no effect on the access to this directory. Instead the default ACL is used to initialize the ACL for any file that is created in this directory. If the new file created is a directory it inherits the default ACL from its parent directory. When an object is created within a directory and the ACL is not defined with the function creating the object, the new object inherits the default ACL of its parent directory as its initial ACL. 7.1.5.3 File system objects File system objects access checks are performed when the object is initially opened, and are not checked on each subsequent access. Changes to access controls (i.e., revocation) are effective with the next attempt to open the object. 7.1.5.4 IPC objects The TOE implements the following standard types of IPC mechanisms: ● SYSV Shared Memory ● SYSV and POSIX Message Queues ● SYSV Semaphores Access to the above mentioned IPC mechanisms are governed by UNIX permission bits. Page 81 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z As the IPC objects of UNIX domain socket special files and Named Pipes are represented as file system objects, the access control mechanism covering file system objects are applicable to these IPC mechanisms too. The TOE maintains IPC object types where each process has its own namespace for that object type: sockets - including network sockets. Access to the socket is only possible by the process whose socket namespace contains the socket reference. Setting of permissions for such objects can be handled using file descriptor passing. This security function covers the SFRs of FDP_ACC.1(TSO), FDP_ACF.1(TSO). 7.1.5.5 at and cron jobs queues at and cron jobs can only be accessed (read/added/modified/deleted) by the owning user. The TOE maintains at and cron job queues for each user. The root user can always access every at or cron job queue. The at or cron jobs are started with the UIDs/GIDs of the creator of the job. 7.1.6 Confidentiality protected data storage File system objects are stored on block devices, such as partitions on hard disk. The Linux operating systems offers the use of an additional layer between the file systems and the physical block device to encrypt and decrypt any data transmitted between the file system and the block device. The dm_crypt functionality uses the Linux device mapper to provide such encryption and decryption operation that is transparent to the file system and therefore to the user. Before mounting the block device that is protected by the dm_crypt encryption scheme, the owner of the encrypted block device has to provide a passphrase. This passphrase is used to decrypt the symmetric session key which is injected into the kernel. Using that session key, the kernel is now able to decrypt (to unlock) the data on the device and provides access to data stored on that device. At this point, the file system can be mounted as the file system can now be read. Once the dm_crypt protected device is unlocked and mounted, it is accessible as any other file system. When it is unmounted and locked (i.e. the kernel is informed to discard the session key), all data on the device is inaccessible. Even administrative users like the root user are not able to access any data any more. When an administrator would access the raw hardware hosting the block device, only encrypted data can be read. For the cryptographic operation, the creator of the dm_crypt block device can select the cipher. When creating the dm_crypt block device, the session key is obtained from the Linux random number generator and stored on the block device encrypted with the user's passphrase. The key derivation mechanism from the user's password is based on the LUKS mechanism. The encryption and decryption operation of the device is implemented by the kernel. To unlock the encrypted session key stored on the protected block device, the cryptsetup application performs the following steps: 1. obtain the user's passphrase 2. apply the LUKS key derivation mechanism on the passphrase 3. read the encrypted session key from the device 4. decrypt the session key with the key derived from the user's passphrase 5. inject the decrypted session key into the kernel Using the cryptsetup tool, the session key can also be transferred by encrypting it with another passphrase which can be given to another user. The transfer follows the same steps outlined for the unlocking operation, but instead of injecting the decrypted session key into the kernel, cryptsetup fetches the new passphrase from the user, applies the LUKS mechanism on that Page 82 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z passphrase, encrypts the session key with the derived key and stores the encrypted session key in a separate area on the device. At this point, the session key is now stored encrypted in two separate places. Similarly, the cryptsetup tool can be used to erase the storage location of one encrypted session key which implies that the user owning the passphrase of the affected encrypted session key is not able to unlock the block device any more. The key material used for by cryptsetup for the disk encryption mechanism is derived from /dev/urandom and XORing 13 bytes from /dev/random into the state random number generator. The installer with the exception of IBM System Z allows the configuration of the full disk encryption schema where the entire disk is protected, except the /boot partition. This security function covers the SFRs of FCS_CKM.1(SYM), FCS_RNG.1(DM), FDP_ACC.2(CP), FDP_ACF.1(CP), FDP_CDP.1, FMT_MSA.1(CP), FMT_MSA.3(CP), FMT_MTD.1(CP-AN), FMT_MTD.1(CP-UD). 7.1.7 Security Management The security management facilities provided by the TOE are usable by authorized users and/or authorized administrators to modify the configuration of TSF. The configuration of TSF are hosted in the following locations: ● Configuration files (or TSF databases) ● Data structures maintained by the kernel and within the kernel memory The TOE provides applications to authorized users as well as authorized administrators to perform various administrative tasks. These applications are documented as part of the administrator and user guidance. These applications are either used to modify configuration files or to access parameters controlled and enforced by the kernel via kernel-provided interfaces to user space. Configuration options are stored in different configuration files. These files are protected using the DAC mechanisms against unauthorized access where usually the root user only is allowed to write to the files. In some special cases (like for /etc/shadow), the file is even readable to the root user only. It is the task of the persons responsible for setting up and administrating the system to ensure that the access control features of the TOE are used throughout the lifetime of the system to protect those databases. These configuration files are accessed using applications which are able to interpret the contents of these configuration files. Each TOE instance maintains its own TSF database. Synchronizing those databases is not performed in the evaluated configuration. If such synchronization is required by an organization it is the responsibility of an administrative user of the TOE to achieve this either manually or with some automated assistance. To access data structures maintained by the kernel, applications use the kernel-provided interfaces, such as system calls, virtual file systems, netlink sockets, and device files. These kernel interfaces are restricted to authorized administrators or authorized users, if applicable, by either using DAC (for virtual file system objects) or special kernel-internal verification checks for each interface. The TOE provides security management applications for all security-relevant settings listed throughout this ST, i.e. all FMT_MSA.1 and FMT_MTD.1 iterations. 7.1.7.1 Privileges 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 Page 83 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 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. Therefore, the root user is given the privilege to perform modifications on this configuration data which constitutes administrative actions. Functionality and data maintained by the kernel must be accessed using system calls. The kernel implements a privilege check for functions and data that shall not be accessible by normal users. These privileges are controlled with capabilities that can be assigned to processes. If a process is assigned with a capability, it is allowed to request special operations that other processes cannot. To implement consistency with the Unix legacy, processes with the effective UID of zero are implicitly given all capabilities. However, these processes may decide to drop capabilities. Such capabilities are marked by names with the prefix of "CAP_" throughout this document. The Linux kernel implements many more capabilities than mentioned in this document. These unmentioned capabilities protect functions that do not directly cover SFR functionality but need to be protected to ensure the integrity of the system and its resources. Page 84 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z 8 Abbreviations, Terminology and References 8.1 Abbreviations ACL Access Control List API Application Programming Interface KVM Kernel Virtualized Machine HTTP Hypertext Transfer Protocol SFR Security Functional Requirement SSL Secure Sockets Layer ST Security Target TCP/IP Transmission Control Protocol / Internet Protocol TLS Transport Layer Security TOE Target of Evaluation TSF TOE Security Functionality VM Virtual Machine VPN Virtual Private Network 8.2 Terminology This section contains definitions of technical terms that are used with a meaning specific to this document. Terms defined in the [CC] are not reiterated here, unless stated otherwise. AppArmor Linux kernel LSM module that is able to implement additional restrictions for executables. A set of AppArmor policies distributed with the TOE provides the separation of resources assigned to virtual machines. Authentication Data Authentication data is the data used by users or remote entities to authenticate their claimed identity. Page 85 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Authorized Administrator This term refers to a user in one of the defined administrative roles of a Linux system. The TOE associates the user with the UID of zero and named "root" with administrative authorities. Effectively, the UID zero is assigned with all Linux capabilities known to the Linux kernel. Every user who is allowed to log on as that root user, or to switch their UID to the root user is considered an authorized administrator. In addition, any user who is able to execute applications which grant one or more Linux capabilities to be used in an unconditional manner is considered an authorized administrator. DAC Discretionary Access Control implemented with permission bits and ACLs. Data Arbitrary bit sequences on persistent or transient storage media. Guest Software executing within a virtual machine environment. There can be zero or more guests executing concurrently on the host system. Host The host system provides the Linux environment that controls and manages the virtual machines. The host provides the execution environment for every virtual machine. Information Any data held within a server, including data in transit between systems. IOMMU Input / Output Memory Management Unit. This MMU allows the setup of multiple DMA areas for different virtual machines. KVM Kernel-based Virtual Machine. Named Object In Linux, those objects that are covered by access control policies. The list of objects defined as named objects is provided with SPM Object For Linux, objects are defined by SPM. OSPP Operating System Protection Profile OSPP EP Operating System Protection Profile Extended Package PAM Pluggable Authentication Module - the authentication functionality provided with Linux is highly configurable by selecting and combining different modules implementing different aspects of the authentication process. Product The term product is used to define software components that comprise the Wind River Linux system. QEMU The QEMU software component implements the virtual devices and virtual resources for virtual machines. There is one instance of QEMU per virtual machine. The QEMU software component is also identified as the "kvm" application on the host system. Page 86 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z Subject There are two classes of subjects in the TOE: i) untrusted internal subject - this is a Linux process running on behalf of some user or providing an arbitrary service, running outside of the TSF (for example, with no privileges); ii) trusted internal subject - this is a Linux process running as part of the TSF (for example: service daemons and the process implementing the identification and authentication of users). Target Of Evaluation (TOE) The TOE is defined as the SUSE Linux Enterprise Server operating system, running and tested on the hardware and firmware specified in this Security Target. The BIOS firmware as well as the hardware are not part of the TOE. User Any individual/person or technical entity (such as a service added by the administrator on top of the TOE) who has a unique user identifier and who interacts with the Wind River Linux product. User Security Attributes Defined by functional requirement FIA_ATD.1, every user is associated with a number of security attributes which allow the TOE to enforce its security functions on this user. This also includes the user clearance which defines the maximum sensitivity label a user can have access to. Virtual devices See virtual resources for a generic explanation. This definition applies also to virtual devices, but with a focus to devices, such as disks, network cards, graphics cards, and similar. Virtual machine A virtual machine is an execution environment where the software executing within the virtual machine has access to the processor's user and supervisor state and resources defined by the host system. Resources include the number of processors, RAM size, physical devices, virtualized devices, communication channels to other virtual machines and the host system. For the KVM environment a virtual machine environment is controlled and provided by the Linux kernel hypervisor functionality plus the QEMU application instantiated for each virtual machine. Virtual machine environment See virtual machine. Virtual resources Virtual resources are resources that either do not physically exist and do not exist in the host system. Virtual resources are implemented by the virtual machine environment and are provided to the respective virtual machine. For example, virtual resources are special exceptions that can be triggered from the virtual machine environment to request services from the host system, such as para-virtualized drivers. Virtual devices can be considered one form of virtual resources. 8.3 References Common Criteria for Information Technology Security Evaluation CC 3.1R3 Version July 2009 Date http://www.commoncriteriaportal.org/files/ccfiles/CC PART1V3.1R3.pdf Location http://www.commoncriteriaportal.org/files/ccfiles/CC PART2V3.1R3.pdf Location http://www.commoncriteriaportal.org/files/ccfiles/CC PART3V3.1R3.pdf Location Page 87 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z BSI Operating System Protection Profile OSPP 2.0 Version 2010 Date Page 88 of 88 Classification: SUSE and atsec public Version: 1.3 Copyright © 2013 by SUSE and atsec information security Last update: 2013-02-19 SUSE Linux Products GmbH SUSE Linux Enterprise Server 11 SP2 on IBM System z