EVALUATION IN CONFIDENCE Logica This document was prepared by: on behalf of: Logica CLEF (LFL), SUN Microsystems Inc. Logica UK Limited, 4150 Network Circle, Chaucer House, Santa Clara, The Office Park, California, Springfield Drive, 95054 Leatherhead, USA. Surrey KT22 7LP, UK. Solaris82/02 SecurityTarget Author: Author: Deniz Kucukreisoglu Document Number: S8.0 2 / 02 Date: 19 March 2003 Version: 1.0 Definitive Abstract This document is the Security Target for the EAL4 Common Criteria v2.1 evaluation of Solaris 8 2/02 developed by Sun Microsystems, Inc. Please Recycle Logica EVALUATION IN CONFIDENCE  1995 Sun Microsystems, Inc. 2550 Garcia Avenue, Mountain View, California 94043-1100 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Portions of this product may be derived from the UNIX® system, licensed from UNIX Systems Laboratories, Inc., a wholly owned subsidiary of Novell, Inc., and from the Berkeley 4.3 BSD system, licensed from the University of California. Third-party software, including font technology in this product, is protected by copyright and licensed from Sun’s Suppliers. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19. The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applications. TRADEMARKS Sun, Sun Microsystems, the Sun logo, SunSoft, the SunSoft logo, Solaris, Trusted Solaris, SunOS, OpenWindows, DeskSet, ONC, ONC+, NFS, NeWSprint, and Trusted NeWSprint are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and may be protected as trademarks in other countries. UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. OPEN LOOK is a registered trademark of Novell, Inc. PostScript and Display PostScript are trademarks of Adobe Systems, Inc. All other product, service, or company names mentioned herein are claimed as trademarks and trade names by their respective companies. All SPARC trademarks are trademarks or registered trademarks of SPARC International, Inc. in the United States and other countries. SPARCcenter, SPARCcluster, SPARCompiler, SPARCdesign, SPARC811, SPARCengine, SPARCprinter, SPARCserver, SPARCstation, SPARCstorage, SPARCworks, microSPARC, microSPARC-II, and UltraSPARC are licensed exclusively to Sun Microsystems, Inc. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK® and Sun™ Graphical User Interfaces were developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUI’s and otherwise comply with Sun’s written license agreements. X Window System is a trademark of X Consortium, Inc. THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN, THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THE PUBLICATION. SUN MICROSYSTEMS, INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAMS(S) DESCRIBED IN THIS PUBLICATION AT ANY TIME. EVALUATION IN CONFIDENCE Logica iii References Standards & Criteria [CC] Common Criteria for Information Technology Security Evaluation, CCIMB-99-031, Version 2.1, August 1999 [CAPP] Controlled Access Protection Profile, Issue 1.d, 8 October 1999 [Sol8_ST_FCS] Solaris 8 FCS (First Customer Shipment) Security Target Ref.: S8.0_101 / ts2_101, Version 1.0, 28 July 2000. [SRN] Security Release Notes, Issue 0.2, November 2002 Logica EVALUATION IN CONFIDENCE iv Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive This Page Intentionally Left Blank EVALUATION IN CONFIDENCE Logica v 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 ST Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 ST Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 CC Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.4 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.6 Document Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 TOE Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Intended Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Evaluated Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1 Target of Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.2 File systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.3 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Summary of Security Features. . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.1 DAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.2 Identification and Authentication . . . . . . . . . . . . . . . . 9 2.4.3 Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.4 Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3 TOE Security Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Threats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Contents Logica EVALUATION IN CONFIDENCE vi Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive 3.2.1 Threats countered by the TOE . . . . . . . . . . . . . . . . . . 12 3.2.2 Threats to be countered by measures within the TOE environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 Organisational Security Policies . . . . . . . . . . . . . . . . . . . . . . . 12 3.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.1 Physical Aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2 Personnel Aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.3 Connectivity Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 13 4 Security Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Security Objectives for the TOE . . . . . . . . . . . . . . . . . . . . . . . 15 4.2 Security Objectives for the TOE Environment . . . . . . . . . . . . 15 5 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1 TOE Security Functional Requirements . . . . . . . . . . . . . . . . . 19 5.1.1 Requirements Taken from Protection Profile(s) . . . . . 19 5.1.2 Protection Profile SFRs Tailored for This Security Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2 Strength of Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3 TOE Security Assurance Requirements. . . . . . . . . . . . . . . . . . 24 5.4 Security Requirements for the IT Environment . . . . . . . . . . . . 24 6 TOE Summary Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1 IT Security Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1.1 Discretionary Access Control (DAC) . . . . . . . . . . . . . 27 6.1.2 Object Reuse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.3 Identification and Authentication . . . . . . . . . . . . . . . . 29 6.1.4 Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.5 Enforcement Functions. . . . . . . . . . . . . . . . . . . . . . . . 32 6.2 Required Security Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 33 6.2.1 Identification and Authentication . . . . . . . . . . . . . . . . 33 6.3 Assurance Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.1 Correlation of Threats, Policies, Assumptions and Objectives. 37 7.2 Security Objectives Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 38 EVALUATION IN CONFIDENCE Logica Contents vii 7.2.1 Complete Coverage - Threats . . . . . . . . . . . . . . . . . . 38 7.2.2 Complete Coverage - Policy . . . . . . . . . . . . . . . . . . . 41 7.2.3 Complete Coverage - Environmental Assumptions . . 42 7.3 Security Requirements Rationale . . . . . . . . . . . . . . . . . . . . . . 42 7.3.1 Complete Coverage - Objectives . . . . . . . . . . . . . . . . 43 7.3.2 Requirements are Mutually Supportive and Internally Consistent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.3.3 Justification for Choice of Assurance Requirements . 47 7.3.4 Strength of Function Claim is Consistent with Security Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.4 TOE Summary Specification Rationale . . . . . . . . . . . . . . . . . 47 7.4.1 IT Security Functions Satisfy Functional Requirements 47 7.4.2 Justification for Compliance of Assurance Measures 49 7.5 PP Claims and Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.5.1 PP Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.5.2 PP Tailoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.5.3 PP Additions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 7.5.4 PP Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Logica EVALUATION IN CONFIDENCE viii Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive This Page Intentionally Left Blank EVALUATION IN CONFIDENCE Logica 1 Introduction 1 1.1 ST Identification Title:Solaris 8 2/02 Security Target Keywords: Solaris 8 2/02, general-purpose operating system, POSIX, UNIX. This document is the security target for the CC evaluation of the Solaris 8 2/02 operating system product, and is conformant to the Common Criteria for Information Technology Security Evaluation [CC]. 1.2 ST Overview This security target documents the security characteristics of the Solaris 8 2/02 operating system. Solaris is a highly-configurable UNIX-based operating system which has been developed to meet the requirements of the C2 class of the U.S. Department of Defence (DoD) Trusted Computer System Evaluation Criteria (TCSEC), including the use of Access Control Lists. These broad requirements are described for the Common Criteria scheme in [CAPP], the Controlled Access Protection Profile. A Solaris 8 2/02 system consists of a number of workstations and/or servers linked together to form a single distributed system. Users share the resources of multiple workstations and/or servers connected together in a single, distributed Trusted Computing Base (TCB). This Solaris 8 2/02 ST is based on the previous Solaris 8 FCS security target with the appropriate changes. 1.3 CC Conformance This ST is conformant to the Controlled Access Protection Profile version 1.d [CAPP]. This ST is CC Part 2 extended and Part 3 conformant, with a claimed Evaluation Assurance Level of EAL4 (see section 7.3.3). 1.4 Structure The structure of this document is as defined by [CC] Part 1 Annex C. Logica EVALUATION IN CONFIDENCE 1 2 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive • Section 2 is the TOE Description. • Section 3 provides the statement of TOE security environment. • Section 4 provides the statement of security objectives. • Section 5 provides the statement of IT security requirements. • Section 6 provides the TOE summary specification, which includes the detailed specification of the IT Security Functions. • Section 7 provides the rationale for the security objectives, security requirements, TOE summary specification and PP claims against [CAPP]. 1.5 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. Action: An action is an execution of a command or system call. Administrative User: This term refers to an administrator of a Solaris 8 2/02 system. Some administrative tasks require the use of the root username and password so that they can become the superuser (with a user ID of 0). Audit Class: This is the name given to the definition of a collective grouping of events representing particular types of activity to be monitored; e.g. file read, network, administrative, application, process, file attribute modify, etc. Authentication data: This includes a user identifier, password and authorisations for each user of the product. CB: Certification Body, a part of CESG (Communications Electronics Security Group) overseeing and monitoring evaluations in the United Kingdom. Common Components: These relate to components of the mid-frame family that share the same or functionally similar hardware such as CPU, memory, Compact PCI Card, SC, I/O assemblies, etc. FCS: First Customer Shipment. IARR: Impact Analysis and Rationale Report, the document which shows platform equivalency across the SunFire mid-frame range of servers. Mid-frame/Mid-range platforms: For the purposes of this security target this means the Sunfire 3800, 4800, 4810 and 6800 servers. Object: In Solaris 8 2/02, objects belong to one of four categories: file system objects, other kernel objects (such as processes, programs and interprocess communication), window system objects and miscellaneous objects. Peripherals: This term should be taken to mean (optional) storage, communications or printing devices that can be used with the TOE platforms. Platform: Refers to servers, workstations or both when contextually appropriate. PP: Protection Profile. EVALUATION IN CONFIDENCE Logica 1 Introduction 3 Product: The term product is used to define all hardware and software components that comprise the distributed Solaris 8 2/02 system. Public object: A type of object for which all subjects have read access, but only the TCB has write access. SB: Sun Blade, a name given to a family of workstation products. SC: System Controller, the component in the mid-frame platforms that boots up the ToE, and performs similar functions to that of an Open BootPROM Security Attributes: As defined by functional requirement FIA_ATD.1, the term ‘security attributes’ includes the following as a minimum: user identifier; group memberships; user authentication data. Server: A computer/device which provides/manages information or services to computers on a network. SF: Security Function OR (alternatively) SunFire, a name given to a family of servers, dependent upon context. SFR: Security Functional Requirement SoF: Strength of Function SPARC: The name given to the processor family that is incorporated into the platforms identified in this security target. SRN: Security Release Notes, see references. Subject: There are two classes of subjects in Solaris 8 2/02: untrusted subject - this is a Solaris 8 2/02 process running on behalf of some user, running outside of the TCB (for example, with no privileges). trusted subject - this is a Solaris 8 2/02 process running as part of the TCB. Examples are service daemons and the processes implementing the windowing system. System: Includes the hardware, software and firmware components of the Solaris 8 2/02 product which are connected/networked together and configured to form a usable system. System Controller: This is an embedded system consisting of the system controller board and the system controller software (own processor, memory, etc.) which provides communication pathways between the platform system components and additionally performs functions replicating those of an ‘Open Boot PROM’. System High: This refers to an IT system where all users of that system are cleared to see the highest level of protective marking of the information present on the system, but do not have a need-to-know all of that information, access to which is controlled. Target of Evaluation (TOE): The TOE is defined as the Solaris 8 2/02 operating system, running and tested on the hardware and firmware specified in this Security Target. The BootPROM firmware forms part of the TOE Environment (see section 5.4). TSF: TOE Security Function. TSP: TOE Security Policy. Logica EVALUATION IN CONFIDENCE 1 4 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive User: Any individual/person who has a unique user identifier and who interacts with the Solaris 8 2/02 product. Workstation: A workstation is a computer intended for individual use that is more capable, powerful and faster than a personal computer. 1.6 Document Layout IT security functions are assigned a unique reference identifier of the form Name.1 to enable ease of reference. For example, DAC.1, Audit.1. EVALUATION IN CONFIDENCE Logica 5 TOEDescription 2 2.1 Introduction The TOE description aims to aid the understanding of the TOE’s security requirements and provides a context for the evaluation. It defines the scope and boundaries of the TOE, both physically and logically, and describes the environment into which the TOE will fit. 2.2 Intended Use Solaris 8 2/02 is a highly-configurable UNIX-based operating system which has been developed to meet “System High” Operation including the use of Access Control Lists. A Solaris 8 2/02 system consists of a number of workstations and/or servers linked together to form a single distributed system. Users share the resources of multiple workstations and/or servers connected together in a single, distributed Trusted Computing Base (TCB). 2.3 Evaluated Configurations 2.3.1 Target of Evaluation This section defines the software that comprise the ToE and the Servers/Workstations that the software runs on. 2.3.1.1 ToE Certification Platforms: Note that the SF V880 and the SB2000 platforms use an Open BootPROM and the SunFire mid-frame platforms make use of the SC component to perform similar tasks to the OpenBOOT PROM; both of which are outside of the scope of this evaluation. The BootPROM and SC are protected by a password commensurate with the appropriate SoF requirement for the environment. The Administrator is responsible for selecting passwords of appropriate strength to meet the Security target requirements. Workstations: The target of evaluation is a (distributed) operating system product running on: Logica EVALUATION IN CONFIDENCE 2 6 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive • Platform1: SunBlade 2000, UltraSPARC III Cu CPU, 1 x (or more) Hard disk, 2 x Firewire External Interfaces, Ethernet Network card, graphics card, built-in audio card, USB keyboard and 2-button mouse, standard DVD-ROM drive, standard floppy disk drive, 1 UltraSCSI (SCSI-3), 1 x Parallel, 2 x Serial External Interfaces; Servers: • Platform 2: Sunfire V880, UltraSPARC III Cu CPU, 1 x (or more) Hard disk, Ethernet Network card, USB keyboard and 2-button mouse, standard DVD-ROM drive, standard floppy disk drive, 1 x Parallel, 2 x Serial External Interfaces; • Platform3: The SunFire mid-frame family including the 3800, 4800, 4810 and the 6800 range of servers. Various configurations of these platforms are possible and the evaluation scope includes all possible combinations/permutations through the testing of representative configurations. An Impact Analysis and Rationale Report, will show platform equivalency across the SunFire midframe family. The possibilities are listed in Table 1 below. 2.3.1.2 Software The Target of Evaluation is based on the following system software: • Solaris 8 2/02, February 2002 (Also known as Update 7). The TOE documentation is supplied on CD-ROM. Platform Specification Sun Fire 3800 Sun Fire 4800 Sun Fire 4810 Sun Fire 6800 Operating Environment Solaris 8 2/02 Operating Environment CPUs 2-8 2-12 2-24 Processor UltraSPARC III Cu Clock speeds 750MHz, 900MHz, 1050MHz & 1200MHz System Board (CPU) Slots 2 3 6 I/O Slots (SBus/PCI) 12 cPCI 16 PCI or 8 cPCI 32 PCI or 16 cPCI I/O Channel Bandwidth 24 GB per second per PCI/cPCI assembly Maximum Memory 64 GB 96 GB 192 GB Maximum Storage (all Fire data center servers sup- port external storage) 35 TB 77 TB Sustained System Band- width 9.6 GB/sec Table 1: Platform Details and Particulars EVALUATION IN CONFIDENCE Logica 2 TOE Description 7 2.3.2 File systems The following filesystem types are supported: • the standard Solaris UNIX filesystem, ufs, without the Trusted Solaris attributes; • the standard remote filesystem access protocol, nfs (V2 and V3); • the MS-DOS formatted filesystem pcfs; and • the High Sierra filesystem for CD-ROM drives, hsfs. In addition to the above file systems a number of “internal” filesystems are supported: • The file descriptor file system, fd, allows programs to access their own file descriptors through the file name space, such as /dev/stdin corresponding to /dev/fd0. • The names file system, namefs (or namfs) allows the arbitrary mounting of any file descriptor on top of another file name. • The doors file system, doorfs allows fast control transfer between processes on the same machine. • The process file system, procfs (/proc), provides access to the process image of each process on the machine as if the process were a “file”. Process access decisions are enforced by DAC attributes inferred from the underlying process’ DAC attributes. 2.3.3 Configurations The evaluated configurations are defined as follows. • any of the product installation configurations may be selected with the exception of the ‘core system support’ option which does not provide the required windowing environment; • the CDE windowing environment must be used in preference to OpenWindows; • role based access control features are not completely implemented in the product and in general, must not be used. • Solaris 8 2/02 supports the use of IPv4 and IPv6; • support for DHCP is not included; • 64 bit architectures are included; • Web Based Enterprise Management Services (WBEM) are not included; • both network and CD installations are supported; • the default configuration for identification and authentication only. Support for other authentication options e.g. smartcard authentication, is not included in the evaluation configuration; • if the system console is used, it must be connect directly to the server/workstation and afforded the same physical protection as the server/workstation. The product comprises one or more of the above listed servers and/or workstations (and optional peripherals) running the above listed system software (a platform running the above listed software is referred to as a “TOE platform” below). Logica EVALUATION IN CONFIDENCE 2 8 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive If the product is configured with more than one TOE platform, they are linked by Ethernet LANs, which may be joined by bridges/routers or by TOE platforms which act as routers/gateways. No other processors may be connected to the Ethernet network, except as noted below. If the product is configured with more than one TOE platform, then the NIS+ service must be used and any NIS+ server(s) must be TOE platforms. Table 2: Typical Evaluation Configuration 2.4 Summary of Security Features The primary security features of the product are: • Discretionary Access Control; • Object Reuse; • Identification and Authentication; • Auditing; and • Enforcement. These primary security features are supported by kernel and process domain separation and reference mediation, which ensure that the features are always invoked and cannot be bypassed. TOE workstations TOE server TOE workstation (Ethernet) (Ethernet) TOE servers EVALUATION IN CONFIDENCE Logica 2 TOE Description 9 2.4.1 DAC Discretionary Access Control (DAC) restricts access to objects, such as files and is based on Access Control Lists (ACLs) and the standard UNIX permissions for user, group and other users. 2.4.2 Identification and Authentication Solaris 8 2/02 provides identification and authentication based upon an unique user identifier and user password combination. 2.4.3 Auditing Solaris 8 2/02 can collect extensive auditing information about security related actions taken or attempted by users, ensuring that users are accountable for their actions. For each such action or event an audit record is generated containing: date and time of the event, user, security attributes and success or failure. This audit trail can be analysed to identify attempts to compromise security and determine the extent of the compromise. 2.4.4 Enforcement The Solaris 8 2/02 security policy is enforced in a manner which ensures that the organisational policies are upheld in the target environment i.e. the integrity of the TSF is protected, kernel and process domain separation is enforced and bypass of the security functions is prevented. Logica EVALUATION IN CONFIDENCE 2 10 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive This Page Intentionally Left Blank EVALUATION IN CONFIDENCE Logica 11 TOESecurityEnvironment 3 3.1 Introduction The statement of TOE security environment describes the security aspects of the environment in which the TOE is intended to be used and the manner in which it is expected to be employed. To this end, the statement of TOE security environment identifies the lists the assumptions made on the operational environment (including physical and procedural measures) and the intended method of use of the for the product, defines the the threats that the product is designed to counter, and the organisational security policies with which the product is designed to comply. 3.2 Threats The assumed security threats are listed below. The IT assets to be protected comprise the information stored, processed or transmitted by the TOE. The term “information” is used here to refer to all data held within a workstation/server, including data in transit between workstations/servers. The TOE counters the general threat of unauthorised access to information, where “access” includes disclosure, modification and destruction. The threat agents can be categorised as either: • unauthorised users of the TOE, i.e. individuals who have not been granted the right to access the system; or • authorised users of the TOE, i.e. individuals who have been granted the right to access the system. The threat agents are assumed to originate from a well managed user community in a non-hostile working environment, and hence the product protects against threats of inadvertent or casual attempts to breach the system security. The TOE is not intended to be applicable to circumstances in which protection is required against determined attempts by hostile and well funded attackers to breach system security. The threats listed below are grouped according to whether or not they are countered by the TOE. Those that are not countered by the TOE are countered by environmental or external mechanisms. Logica EVALUATION IN CONFIDENCE 3 12 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive 3.2.1 Threats countered by the TOE [T.ACCESS_INFO] An authorised user of the TOE accesses information without having permission from the person who owns, or is responsible for, the information. In this context ‘access’ is to be interpreted as observing information for which the user has no ‘need to know’, even though that user may have sufficient clearance to see the information. [T.ACCESS_TOE] An unauthorised user of the TOE gains access to the system, thereby gaining unauthorised access to information. An unauthorised user of the TOE could gain access to the system by impersonating an authorised user, or by gaining access to an unattended platform at which an authorised user is logged on. Failure to detect the fact that an attack is taking place, or that many attempts have taken place over a period of time, may result in the attack eventually succeeding, resulting in the attacker gaining unauthorised access to information. [T.MODIFY] Unauthorised modification or destruction of information by an authorised user of the TOE. In this context ‘unauthorised’ means not having the explicit or implicit permission of the designated owner of the information. [T.ADMIN_RIGHTS] Unauthorised use of facilities which require administration rights by an authorised user of the TOE. Unauthorised use of such facilities by a user who cannot be trusted not to misuse them (whether intentionally or accidentally) could be exploited to gain unauthorised access to information. 3.2.2 Threats to be countered by measures within the TOE environment The following threats apply in environments where specific threats to distributed systems need to be countered. [T.TRANSIT] Data transferred between platforms is disclosed to or modified by unauthorised users or processes either directly or indirectly (e.g. through spoofing of workstation/server identity). 3.3 Organisational Security Policies The TOE complies with the following organisational security policies: [P.AUTH] Only those users who have been authorised to access the information within the system may access the system. [P.DAC] The right to access specific data objects is determined on the basis of: a. the owner of the object; and b. the identity of the subject attempting the access; and c. the implicit and explicit access rights to the object granted to the subject by the object owner. EVALUATION IN CONFIDENCE Logica 3 TOE Security Environment 13 [P.ACCOUNTABLE] The users of the system shall be held accountable for their actions within the system. 3.4 Assumptions This section indicates the minimum physical and procedural measures required to maintain security of the Solaris 8 2/02 product. It is not a complete list, as specific measures may be required for different configurations and sites. 3.4.1 Physical Aspects [A.PROTECT] It is assumed that all software and hardware, including network and peripheral cabling is approved for the transmittal of the most sensitive data held by the system. Such items are assumed to be physically protected against threats to the confidentiality and integrity of the data transmitted. 3.4.2 Personnel Aspects [A.ADMIN] It is assumed that there are one or more competent individuals who are assigned to manage the TOE and the security of the information it contains. Such personnel are assumed not to be careless, wilfully negligent or hostile. 3.4.3 Connectivity Aspects [A.NIS_DOMAINS] It is assumed that, if the product comprises more than one platform, all platforms are administered from a central point within each NIS+ domain. NIS+ allows the creation of multiple administrative domains, thus allowing administrators to control local resources and user accounts, yet making it possible for users and resources to operate seamlessly over the entire organisation. [A.BRIDGES&ROUTERS] All bridges and routers are assumed to correctly pass data without modification. Logica EVALUATION IN CONFIDENCE 3 14 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive This Page Intentionally Left Blank EVALUATION IN CONFIDENCE Logica 15 SecurityObjectives 4 4.1 Security Objectives for the TOE [O.AUTHORISATION] The TOE must ensure that only authorised users gain access to the TOE and its resources. [O.DAC] The TOE must provide its users with the means of controlling and limiting access to the objects and resources they own or are responsible for, on the basis of individual users or identified groups of users, and in accordance with the set of rules defined by the P.DAC security policy. [O.AUDIT] The TOE must provide the means of recording any security relevant events, so as to: a. assist an administrator in the detection of potential attacks or misconfiguration of the TOE security features that would leave the TOE susceptible to attack; and b. hold users accountable for any actions they perform that are relevant to security. [O.RESIDUAL_INFO] The TOE must ensure that any information contained in a protected resource is not released when the resource is recycled. [O.MANAGE] The TOE must allow administrators to effectively manage the TOE and its security functions, and must ensure that only authorised administrators are able to access such functionality. [O.ENFORCEMENT] The TOE security policy is enforced in a manner which ensures that the organisational policies are enforced in the target environment i.e. the integrity of the TSF is protected. 4.2 Security Objectives for the TOE Environment [O.ADMIN] Those responsible for the TOE are competent and trustworthy individuals, capable of managing the TOE and the security of the information it contains. [O.ACCOUNTABLE]Those responsible for the TOE must ensure that: a. The product is configured such that only the approved group of users for which the system was accredited may access the system. b. Each individual user is assigned a unique user ID. Logica EVALUATION IN CONFIDENCE 4 16 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive [O.AUDITDATA] Those responsible for the TOE must ensure that the audit functionality is used and managed effectively. In particular: a. Procedures must exist to ensure that the audit trail for the product (i.e., all networked components containing an audit trail) is regularly analysed and archived, to allow retrospective inspection. b. The auditing system must be configured such that the loss of audit data is minimised upon: • planned or unplanned shutdown; or • lack of available audit storage (in particular administrators should ensure that the AUDIT_CNT flag is correctly set as identified in the Administration documentation supplied with the TOE, and that remote partitions are mounted with the appropriate option [noac] so that audit information is not lost when the partition fills). c. The auditing system must be configured such that bad authentication data will not be stored in the audit trail (in particular, administrators should ensure that the PASSWD flag is correctly set as identified in the Administration documentation supplied with the TOE). d. The media on which audit data is stored must not be physically removable from the platform by unauthorised users. [O.AUTHDATA] Those responsible for the TOE must ensure that user authentication data is stored securely and not disclosed to unauthorised individuals. In particular: a. Procedures must be established to ensure that user passwords generated by an administrator during user account creation or modification are distributed in a secure manner, as appropriate for the clearance of the system. b. The media on which authentication data is stored must not be physically removable from the platform by unauthorised users. c. Users must not disclose their passwords to other individuals. [O.BOOT] Hardware and firmware within the IT environment shall ensure that the correct copy of the Solaris 8 2/02 operating system is “booted” during system start-up. Note: The above applies to both workstations and server. Administrators should also take precautions to prevent booting from the floppy drive, CD device or over the network where this is considered a threat. [O.CONSISTENCY] Administrators of the TOE must establish and implement procedures to ensure the consistency of the security-related data across all distributed components that are networked to form a single system (e.g. authentication data). In particular, if the product comprises more than one platform, all such platforms are administered from a central point within each NIS+ domain. [O.INSTALL] Those responsible for the TOE must establish and implement procedures to ensure that the hardware, software and firmware components that comprise the networked product are distributed, installed and configured in a secure manner. EVALUATION IN CONFIDENCE Logica 4 Security Objectives 17 [O.INFO_PROTECT]Those responsible for the TOE must establish and implement procedures to ensure that information is protected in an appropriate manner. In particular: a. DAC protections on security critical files (such as audit trails and authentication databases) shall always be set up correctly. b. 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. [O.MAINTENANCE] Administrators of the TOE must ensure that the comprehensive diagnostics facilities provided by the product are invoked at every scheduled preventative maintenance period. [O.RECOVER] Those responsible for the TOE must ensure that procedures and/or mechanisms are provided to assure that, after system failure or other discontinuity, recovery without a protection (i.e., security) compromise is obtained. [O.SOFTWARE_IN] Those responsible for the TOE shall ensure that the system shall be configured so that only an administrator can introduce new software into the system. [O.SERIAL_LOGIN] Those responsible for the TOE shall implement procedures to ensure that users clear the screen before logging off where serial login devices (e.g.VT100) are used. The following security objective applies in environments where specific threats to distributed systems need to be countered, as described in section 3. Typically this objective is met by cryptographic protection of network connections. [O.PROTECT] Those responsible for the TOE must ensure that procedures and/or mechanisms exist to ensure that data transferred between platforms is secured from disclosure, interruption or tampering. Logica EVALUATION IN CONFIDENCE 4 18 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive This Page Intentionally Left Blank EVALUATION IN CONFIDENCE Logica 19 SecurityRequirements 5 5.1 TOE Security Functional Requirements 5.1.1 Requirements Taken from Protection Profile(s) The security functional requirements for the TOE are as defined in [CAPP] with refinements to SFRs that are left to the security target author. The following table lists the classes, families, components and elements defined in [CAPP]. These all apply to the TOE, but the elements that are to be tailored for this security target are indicated by a * after the element’s name. CLASS FAMILY COMPONENT ELEMENT [CAPP] PARAGRAPH FAU FAU_GEN FAU_GEN.1 FAU_GEN.1.1 FAU_GEN.1.2 5.1.1.1 5.1.1.2 FAU_GEN.2 FAU_GEN.2.1 5.1.2.1 FAU_SAR FAU_SAR.1 FAU_SAR.1.1 FAU_SAR.1.2 5.1.3.1 5.1.3.2 FAU_SAR.2 FAU_SAR.2.1 5.1.4.1 FAU_SAR.3 FAU_SAR.3.1* 5.1.5.1 FAU_SEL FAU_SEL.1 FAU_SEL.1.1* 5.1.6.1 FAU_STG FAU_STG.1 FAU_STG.1.1 FAU_STG.1.2 5.1.7.1 5.1.7.2 FAU_STG.3 FAU_STG.3.1* 5.1.8.1 FAU_STG.4 FAU_STG.4.1* 5.1.9.1 FDP FDP_ACC FDP_ACC.1 FDP_ACC.1.1* 5.2.1.1 Table 3: Security Functional Requirements Logica EVALUATION IN CONFIDENCE 5 20 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive FDP_ACF FDP_ACF.1 FDP_ACF.1.1* FDP_ACF.1.2* FDP_ACF.1.3* FDP_ACF.1.4* 5.2.2.1 5.2.2.2 5.2.2.3 5.2.2.4 FDP_RIP FDP_RIP.2 FDP_RIP.2.1 5.2.3.1 FDP_RIP FDP_RIP.2 (Note1) FDP_RIP.2.1 5.2.3.2 FIA FIA_ATD FIA_ATD.1 FIA_ATD.1.1* 5.3.1.1 FIA_SOS FIA_SOS.1 FIA_SOS.1.1 5.3.2.1 FIA_UAU FIA_UAU.1 FIA_UAU.1.1* FIA_UAU.1.2 5.3.3.1 5.3.3.2 FIA_UAU.7 FIA_UAU.7.1 5.3.4.1 FIA_UID FIA_UID.1 FIA_UID.1.1* FIA_UID.1.2 5.3.5.1 5.3.5.2 FIA_USB FIA_USB.1 FIA_USB.1.1;1* FIA_USB.1.1;2* FIA_USB.1.1;3* 5.3.6.1 5.3.6.2 5.3.6.3 FMT FMT_MSA FMT_MSA.1 FMT_MSA.1.1* 5.4.1.1 FMT_MSA.3 FMT_MSA.3.1 FMT_MSA.3.2* 5.4.2.1 5.4.2.2 FMT_MTD FMT_MTD.1 FMT_MTD.1.1;1 FMT_MTD.1.1;2 FMT_MTD.1.1;3 FMT_MTD.1.1;4 FMT_MTD.1.1;5 5.4.3.1 5.4.4.1 5.4.5.1 5.4.6.1 5.4.6.2 FMT_REV FMT_REV.1 FMT_REV.1.1;1 FMT_REV.1.2;1* FMT_REV.1.1;2 FMT_REV.1.2;2* 5.4.7.1 5.4.7.2 5.4.8.1 5.4.8.2 FMT_SMR FMT_SMR.1 FMT_SMR.1.1* FMT_SMR.1.2 5.4.9.1 5.4.9.2 FPT FPT_AMT FPT_AMT.1 FPT_AMT.1.1* 5.5.1.1 FPT_RVM FPT_RVM.1 FPT_RVM.1.1 5.5.2.1 FPT_SEP FPT_SEP.1 FPT_SEP.1.1 FPT_SEP.1.2 5.5.3.1 5.5.3.2 FPT_STM FPT_STM.1 FPT_STM.1.1 5.5.4.1 CLASS FAMILY COMPONENT ELEMENT [CAPP] PARAGRAPH Table 3: Security Functional Requirements EVALUATION IN CONFIDENCE Logica 5 Security Requirements 21 5.1.2 Protection Profile SFRs Tailored for This Security Target The elements in [CAPP] that are tailored for this security target are indicated by a * after the element’s name in the table above. These tailored elements are given below, with the new material underlined. The remaining SFRs in the table above are to be used for this security target exactly as they appear in [CAPP]. 5.1.2.1 Security Audit (FAU) 5.1.5.1 The TSF shall provide the ability to perform searches of audit data based on the following attributes: FAU_SAR.3.1 a. User identity; b. type of audit event and audit class. 5.1.6.1 The TSF shall be able to include or exclude auditable events from the set of audited events based on the following attributes: FAU_SEL.1.1 a. User identity; b. audit class. 5.1.8.1 The TSF shall generate an alarm to the authorized administrator if the audit trail exceeds or meets 100% occupancy. FAU_STG.3.1 Note: An alarm is generated once 100% of the allocated audit space is reached. This disk space may be exceeded in certain circumstances e.g. by auditable actions taken by authorised administrators. 5.1.9.1 The TSF shall be able to prevent auditable events, except those taken by the authorized administrator, if the audit trail is full. FAU_STG.4.1 5.1.2.2 User Data Protection (FDP) 5.2.1.1 The TSF shall enforce the Discretionary Access Control Policy on processes acting on the behalf of users, filesystem objects and all operations among subjects and objects covered by the DAC policy. FDP_ACC.1.1 5.2.2.1 The TSF shall enforce the Discretionary Access Control Policy to objects based on the following: FDP_ACF.1.1 a. The user identity and group membership(s) associated with a subject; and b. The access control attributes associated with an object: ACL, permission bits 5.2.2.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: FDP_ACF.1.2 IF the object has an explicit ACL, THEN: - access granted to the object’s owner is based on the user::rwx permissions - access granted to individuals specified in the ACL is based on the bitwise AND operation of the user:[specified]:rwx and mask:rwx permissions - access granted to subjects who belong to the object’s group is based on the bitwise AND operation of the group::rwx and the mask:rwx entries Logica EVALUATION IN CONFIDENCE 5 22 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive - access granted to subjects who belong to groups specified in the ACL is based on the bitwise AND operation of the group:[specified]:rwx and mask:rwx permissions - access granted to all other subjects is based on the object’s other permissions ELSE - access granted to the object’s owner is based on the object user rwx permissions - access granted to subjects who belong to the object’s group is based on the object group rwx permissions - access granted to all other subjects is based on the object other rwx permissions 5.2.2.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rule: FDP_ACF.1.3 a. If a subject has an effective UID of 0, the TSF shall authorize access of the subject to any given filesystem object, even if such access is disallowed by FDP_ACF.1.2. 5.2.2.4 The TSF shall explicitly deny access of subjects to objects based on no additional rules. FDP_ACF.1.4 5.1.2.3 Identification and Authentication (FIA) 5.3.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: FIA_ATD.1.1 a. User Identifier; b. Group Memberships; c. Authentication Data; d. Security-relevant Roles; and e. login shell. 5.3.3.1 The TSF shall allow the following TSF-mediated actions on behalf of the user to be performed before the user is authenticated a. select language; b. select desktop or console login; c. select remote host for login; d. help for login function. FIA_UAU.1.1 5.3.5.1 The TSF shall allow the following TSF-mediated actions on behalf of the user to be performed before the user is identified. a. select language; b. select desktop or console login; c. select remote host for login; d. help for login function. FIA_UID.1.1 EVALUATION IN CONFIDENCE Logica 5 Security Requirements 23 5.3.6.1 The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: FIA_USB.1.1;1 a. The audit user identity; b. The effective user identity; c. The effective group identities; d. The real user identity and real group identities. 5.3.6.2 The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of a user: FIA_USB.1.1;2 a. Upon successful identification and authentication, the real and effective and audit user identities shall be those specified via the User Identifier attribute held by the TSF for the user. b. Upon successful identification and authentication, the real and effective group identities shall be those specified via the Group Memberships attributes held by the TSF for the user. 5.3.6.3 The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of a user: FIA_USB.1.1;3 a. The effective user identity associated with a subject can be changed to another user’s identity via a command, provided that the effective user identity was 0, or successful authentication as the new user identity has been achieved; b. When executing a file which has the set UID permission bit set, the effective user identity associated with the subject shall be changed to that of the owner of the file; c. When executing a file which has the set GID permission bit set, the effective group identity associated with the subject shall be changed to that of the group attribute of the file. Application Note: The DAC policy is enforced based on the effective UID as described above. All auditable events are recorded with the audit ID, which contains the identity of the user at identification time. In this manner, all auditable events can be traced back to the person initially identified to the TOE and are not associated to another person who may at some time identify them self as the alternate identity. 5.1.2.4 Security Management (FMT) 5.4.1.1 The TSF shall enforce the Discretionary Access Control Policy to restrict the ability to modify the access control attributes associated with a named object to the subject that owns the object and a subject with an effective UID of 0.FMT_MSA.1.1;1 5.4.2.2 The TSF shall allow the authorised administrators and users authorised by the Discretionary Access Control Policy to modify object security attributes to specify alternative initial values to override the default values when an object or information is created.FMT_MSA.3.2 5.4.7.2 The TSF shall enforce the rules: FMT_REV.1.2;1 a. The immediate revocation of security-relevant authorizations; and Logica EVALUATION IN CONFIDENCE 5 24 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive b. Administrative users shall be able to revoke security-relevant authorisations by completely deleting user security attributes, or by modifying the user identity, user name, primary group, secondary group and login shell, or by setting a new password. Such revocation is to take effect when the user next authenticates to the system. 5.4.8.2 The TSF shall enforce the rules: FMT_REV.1.2;2 a. The access rights associated with an object shall be enforced when an access check is made. 5.4.9.1 The TSF shall maintain the roles: FMT_SMR.1.1 a. authorized administrator; b. users authorised by the Discretionary Access Control Policy to modify object security attributes; c. users authorised to modify their own authentication data. 5.1.2.5 Protection of the TOE Security Functions (FPT) 5.5.1.1The TSF shall run a suite of tests at the request of an authorized administrator to demonstrate the correct operation of the security assumptions provided by the abstract machine that underlies the TSF. FPT_AMT.1.1 5.2 Strength of Function The claimed minimum strength of function is SOF-medium. 5.3 TOE Security Assurance Requirements The target evaluation assurance level for the product is EAL4 [CC]. No augmented assurance requirements are defined. 5.4 Security Requirements for the IT Environment The IT environment is required to meet the objectives described in Section 4.2. All but one of these objectives is met by procedural measures, however O.BOOT is met by the OpenBoot PROM on the SunFire V880 and SunBlade 2000 or the SC on the SunFire mid-frame platforms. Refinements are identified by emboldened text. The functionality provided by this firmware/SC is specified as follows: The OpenBoot PROM on SF V880 & SB2000 or the SC on the SunFire mid-frame platforms shall restrict the ability to modify the behaviour of the boot strapping process to users who know the valid PROM or SC (respectively) password.FMT_MOF.1 Application Note: In fully secure and command-secure modes, the valid (booting) password is required in order to configure PROM operating modes, PROM passwords or boot parameters as required by the [SRN]. The operation of the SC and its associated functionality is password protected. Application Note: The use of emboldened text in the above SFR signifies refinement of the CC Part 2 functional component. EVALUATION IN CONFIDENCE Logica 5 Security Requirements 25 Note: The SunFire V880 and SB2000 platforms use a BootPROM to ensure that a correct copy of the ToE is instantiated at start-up. The SunFire mid-frame platforms use the SC to ensure that a correct copy of the TOE is instantiated at start-up. It is the responsibility of the Administrator to ensure that the SoF for the IT environment is commensurate with the SoF of the ToE (i.e. medium). It is envisaged that it will be necessary to implement appropriate procedural mechanisms to achieve this; for example with respect to the choice of password. Logica EVALUATION IN CONFIDENCE 5 26 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive This Page Intentionally Left Blank EVALUATION IN CONFIDENCE Logica 27 TOE Summary Specification 6 6.1 IT Security Functions The ITSFs to which the claimed Strength of Function (SoF) rating applies are as follows: • IA.1 • IA.11 6.1.1 Discretionary Access Control (DAC) Policy The security-related software shall define and control access between named users and named objects (e.g., files and programs) in the data processing system. All named users and named objects shall be uniquely identifiable over all the platforms in the system. Within Solaris, DAC is applied in two different ways depending on the type of object. This security target therefore defines two object types: • Objects that have permissions that can be changed by the owner; • Objects that have permissions that are fixed or implicit given a process context. The enforcement mechanisms for the former type of object shall allow users to specify and control sharing of those objects, initially generated by the user, by named users (group control is optional) using the specific designations of read, write, execute/search. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorised access. These access controls shall be capable of including or excluding access down to the level of a single user. Access permission to these objects by users not already possessing access permission shall only be assigned by an authority responsible and authorised to grant access. Subjects have a number of IDs associated with them:- Logica EVALUATION IN CONFIDENCE 6 28 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive • effective user ID, real user ID, saved user ID; • effective group ID, real group ID, saved group ID, supplemental groups; and • audit user ID. The Solaris 8 2/02 discretionary access controls use the effective user ID and effective group ID for policing a subject’s access rights over objects that have fixed or implicit permissions to within a process context. Self/Group/Public/ACL Permissions The product shall implement a discretionary access control mechanism that controls the access of subjects to named owner controlled objects. The discretionary access control mechanism shall associate with each object, an owner identification, a group identification, a set of access permissions and/or an access control list (ACL). DAC.1 Subject to DAC.8 the access permissions on an owner controlled object can be modified only by a subject that owns the object. DAC.2 No subject may change the owner or group of an owner controlled object unless it has a uid of 0, or optionally is the owner of the object. Note that Solaris 8 2/02 can be configured to allow the modification of owner and group of a owner controlled object by the owner, or can be configured to be POSIX compliant whereby only the root user (uid 0) can modify ownership, and the owner can change the group only to one which they are a member of. The functioning of both of these modes should be assessed during the evaluation of the TOE. DAC.3 Subject to DAC.1, a subject may assign any combination of the following access modes to an owner controlled object:- • read, write, execute/search to:- • the owner of the object (self); • any member of the owning group (group); and • any user other than the owner or a member of the owning group (other). DAC.4 Subject to DAC.1, an Access Control List (ACL) can be created for a ufs or nfs filesystem object to specify a set of allowable access modes (as per DAC.3) for individually named users or groups. If an ACL entry for a user or group contains no access modes, the specified user or group is specifically excluded from accessing the object. Users not listed anywhere in an ACL (either through explicit user ACL entries or through any applicable group ACL entries) shall have their access to the object determined by the “Other” ACL entry. Note that the scope of the above Security Function is limited to regular files held on ufs and nfs filesystems. This includes hard links but excludes device special files, pipes and symbolic links. However, the regular files referenced by symbolic links can still be controlled by ACLs. DAC.6 Whenever a subject requests access to an owner controlled object, the access permissions for that object shall be checked to determine whether the user who owns the subject can access the object in the requested mode. Where an ACL is defined for an object, it shall be used instead of the object’s permission bits. EVALUATION IN CONFIDENCE Logica 6 TOE Summary Specification 29 DAC.7 When a subject creates a filesystem object, the user ID of the subject is assigned to the object, and the user’s umask restricts the initial access permissions of the object. The TOE default is that a user’s umask is set to prevent any user other than the owner having write access to the object. DAC.8 Subjects may only override discretionary access control if they have a uid of 0. 6.1.2 Object Reuse OR.1 When an object is initially assigned, allocated or reallocated to a subject from the system’s pool of unused objects, the security-related software shall assure that the object contains no data for which the subject is not authorised. OR.2 When memory objects are allocated for use by a subject at run-time, the memory shall contain no data from a previous subject. Any portion of a file object that has not been previously written to shall either: • not be readable by any subject; or • shall be cleared before it can be read. OR.3 The TOE shall revoke all access rights held by a subject to the information contained within a storage object, before reuse by other subjects. 6.1.3 Identification and Authentication Password Authentication IA.1 The product shall require users to identify and successfully authenticate themselves, using a user name and a password, before performing any other actions. IA.2 Upon successful identification and authentication, the real and audit user IDs and the real group IDs of the user’s subjects shall be those specified by the authentication data. Password Protection The authentication data shall not contain a clear text version of each user’s password, but rather a one-way encrypted value based on the user’s password. When a user enters his password, it is used to construct an encrypted value and is compared against the encrypted value in the authentication data. IA.9 On entry, passwords shall not be displayed in cleartext. IA.10 User passwords are always stored in encrypted form. Note: This SF does not apply to BOOTPROM or SC passwords (which are not user passwords, and are beyond the scope of this security target). IA.11 The authentication data shall be protected so that it cannot be written other than as follows: • by administrative users who may • create, delete user identities, • modify the name, primary group, secondary group, login shell; • set passwords if required; and Logica EVALUATION IN CONFIDENCE 6 30 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive • by a user supplying a new password. Note: In respect of [CAPP_5.4.7.2] requirements; The administrator can use the Administration tools to revoke access rights, security relevant authorisations and forcibly log off users if required. 6.1.4 Audit Audit Events Audit.1 The use of the identification and authentication mechanisms is auditable. The following information is recorded for each event audited:- • date; • time; • user identity - audit ID and effective user ID (if successful); • security attributes of the user (if successful) • identification of the server/workstation or terminal used; and • success or failure of the event. Audit.2 Attempts to access to objects are auditable. The following information is recorded for each event audited:- • date; • time; • user identity - audit ID and effective user ID; • name of the object; • type of access attempted; and • success or failure of the attempt. Audit.3 The creation of an object is auditable. The following information is recorded for each event audited: • date; • time; • user identity - audit ID and effective user ID; • name of the object. Audit.4 The creation of a subject to run on behalf of a user is auditable. The following information is recorded for each event audited: • date; • time; • user identity - audit ID and effective user ID; • success or failure of the attempt; Audit.5 The creation, deletion, disabling or enabling of user accounts is auditable. The following information is recorded for each event audited: • date; • time; • identity of the user implementing the change - audit ID and effective user ID; • name of the user account being modified; and • type of action. EVALUATION IN CONFIDENCE Logica 6 TOE Summary Specification 31 Audit.6 Attempts to assign or modify security attributes are auditable. The following information is recorded for each event audited: • date; • time; • identity of the user implementing the change - audit ID and effective user ID; • name of the user account or object being modified; • type of attribute; and • success or failure of the attempt. Audit.7 The assuming of uid 0 is auditable. The following information is recorded for each event audited: • date; • time; • user identity - audit ID and effective user ID; • name of the object involved (if any). Audit.8 Security relevant events affecting the operation of the auditing functions are auditable. The following information is recorded for each event audited: • date; • time; • user identity (if relevant) - audit ID and effective user ID; and • type of event. Audit.10 The creation or deletion of a logical device for storage media is auditable. The following information is recorded for each event audited: • date; • time; • user identity (if relevant) - audit ID and effective user ID; • name of the object and device; and • type of action. Audit.11 Start-up and shutdown of the system is auditable. The following information is recorded for each event audited: • date; • time; • user identity (mandatory for shutdown only) - audit ID and effective user ID; and • type of event. Audit.12 The date and time information recorded in audit records shall be reliable. Protection of Audit Information Audit.14 Audit data shall be protected so that access to it is limited to administrative users. Audit.15 Password data (in clear or encrypted form) is never recorded in the audit log. Selective Audit Data Collection/Reduction Audit.16 Only administrative users may define classes of audit event. Audit.17 Only administrative users shall be able to define the default system audit- mask that defines which audit classes are recorded by default. Logica EVALUATION IN CONFIDENCE 6 32 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive Audit.18 Only administrative users shall be able to define a per-user audit-mask that defines which audit classes are recorded for that user. For a given user, the system shall audit those classes that are in the default system audit mask or the per-user audit mask. Audit.19 Audit reduction software shall be available to allow administrative users to selectively retrieve audit data based on, at a minimum, the identity of users, the type of audit event, and the audit class. Audit Data Storage Audit.20 Each server/workstation of the (distributed) product may store audit data locally or on another server/workstation of the product that can act as an audit server. Audit.21 If another server/workstation of the product is being used as an audit server, and this audit server becomes unavailable, the (local) server/workstation shall either: • automatically switch over to storing audit data locally, or • suspend operation until the audit server is again available, or • suspend operation until an alternative server/workstation of the product takes over as an audit server; or • if no server/workstation is able to store audit data then no further auditable events shall occur (ie., all auditable actions will be suspended). Audit.22 Facilities are available to allow administrative users to archive and maintain the audit logs. Only such users may use these facilities to archive and maintain the audit logs. Audit.23 The system shall notify an administrator of audit trail saturation. 6.1.5 Enforcement Functions ENF.1 The TOE shall validate all actions between subjects and objects that require policy enforcement, before allowing the action to succeed. ENF.2 The TOE shall maintain a domain ‘kernel space’ for its own trusted execution. This shall be kept separate from untrusted subjects each of which operates in its own ‘user space’. ENF.3 The TOE shall allow an administrator to perform a self test to ensure that the underlying TSF is enforcing process separation. EVALUATION IN CONFIDENCE Logica 6 TOE Summary Specification 33 6.2 Required Security Mechanisms 6.2.1 Identification and Authentication The TOE uses a username and password mechanism to provide authentication of users. The construction of passwords is sufficient to meet the requirements of a strength of function of Medium. This mechanism supports the IT SFs IA.1 and IA.11. Passwords are encrypted using a proprietary one way hashing algorithm, however the assessment of algorithmic strength does not form part of the evaluation. 6.3 Assurance Measures Assurance measures will be adopted to address each of the EAL4 assurance requirements, as summarised in Table B.1 in [CC, Part 3] and as summarised below. Assurance components Assurance Measure ACM_AUT.1 Partial CM automation Information on the automated CM tools will be provided in the Software Development Framework document ACM_CAP.4 Generation support and acceptance procedures Configuration Management procedures will be provided for Solaris 8 2/02. ACM_SCP.2 Problem tracking CM coverage As for ACM_CAP.4. ADO_DEL.2 Detection of modification Delivery procedures will be provided for Solaris 8 2/02. ADO_IGS.1 Installation, generation, and start-up procedures Installation, generation and start-up procedures will be provided for Solaris 8 2/02. ADV_FSP.2 Fully defined external interfaces The Solaris 8 2/02 MAN pages, which are relevant to the implementation of the security functions, will be provided to the evaluation and assessed against this assurance requirement. ADV_HLD.2 Security enforcing high-level design High-level Design will be provided for Solaris 8 2/02. ADV_IMP.1 Subset of the implementation of the TSF The source code for Solaris 8 2/02 will be provided to the evaluation. ADV_LLD.1 Descriptive low-level design Low-level Design will be provided for Solaris 8 2/02. Logica EVALUATION IN CONFIDENCE 6 34 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive ADV_RCR.1 Informal correspondence demonstration This correspondence information will be contained in the functional specification and design documents. The functional specification will map SFs to MAN pages. The HLD will map ITSFs to the HLD, and the LLD will map ITSFs and source code modules to the LLD basic components ADV_SPM.1 Informal TOE security policy model A separate Informal Security Policy Model (ISPM) will be provided to the evaluation. AGD_ADM.1 Administrator guidance The Solaris 8 2/02 operational documentation relevant to an administrator will be provided. AGD_USR.1 User guidance The Solaris 8 2/02 operational documentation relevant to an end user will be provided. ALC_DVS.1 Identification of security measures Development security documentation will be provided for Solaris 8 2/02. ALC_LCD.1 Developer defined life-cycle model The Life Cycle definition for Solaris 8 2/02 is documented in the Software Development Framework document. ALC_TAT.1 Well-defined development tools The tools used in the development of Solaris 8 2/02 are the same as for Solaris 8 FCS. ATE_COV.2 Analysis of coverage The analysis of test coverage will be presented to the evaluation in a form similar to that provided to the Solaris 8 FCS evaluation. The existing coverage is against both High and Low level designs and should therefore be to a sufficient depth. ATE_DPT.1 Testing: high-level design The analysis of test depth will be presented to the evaluation in a form similar to that provided to the Solaris 8 FCS evaluation. The existing coverage is against both High and Low level designs and should therefore be to a sufficient depth ATE_FUN.1 Functional testing The test documentation provided to the evaluation will be in a format similar to that provided to the Solaris 8 FCS evaluation. The tests will be run on a range of platforms as specified in section 2.3.1.1. ATE_IND.2 Independent testing - sample Access will be provided to the TOE in its evaluated configuration on an appropriate set of platforms, together with all resources needed to repeat the developer’s tests. Assurance components Assurance Measure EVALUATION IN CONFIDENCE Logica 6 TOE Summary Specification 35 Table 4: How Assurance Requirements Will Be Met AVA_MSU.2 Validation of analysis The Misuse Analysis, previously submitted for the EAL4 evaluation of Solaris 8 FCS, will be updated for Solaris 8 2/02. AVA_SOF.1 Strength of TOE security function evaluation The Strength of Function analysis, previously submitted for the EAL4 evaluation of Solaris 8 FCS, will be updated for Solaris 8 2/02. AVA_VLA.2 Independent vulnerability analysis The Developer Vulnerability Analysis, previously submitted for the EAL4 evaluation of Solaris 8 FCS, will be updated for Solaris 8 2/02 and submitted to the evaluation against this requirement. In addition, evidence of Sun’s continuing search for vulnerabilities and the resolution of them in the Solaris product, will be provided. Assurance components Assurance Measure Logica EVALUATION IN CONFIDENCE 6 36 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive This Page Intentionally Left Blank EVALUATION IN CONFIDENCE Logica 37 Rationale 7 This chapter presents the evidence used in the Security Target evaluation. This evidence supports the claims that the ST is a complete and cohesive set of requirements, that a conformant TOE would provide an effective set if IT security countermeasures within the security environment, and that the TOE summary specification addresses the requirements. The rationale also demonstrates that any PP conformance claims are valid. 7.1 Correlation of Threats, Policies, Assumptions and Objectives. The correlation between threats, organisational policies, assumptions and objectives is detailed in the following sections, and is summarised below. Objectives O.Authorisation O.Dac O.Audit O.Residual_Info O.Manage O.Enforcement O.Admin O.Accountable O.AuditData O.AuthData O.Boot O.Consistency O.Install O.Info_Protect O.Maintenance O.Recover O.Software_in O.Serial_Login O.Protect Threats T.Access_Info                T.Access_TOE            T.Modify           T.Admin_Rights            T.Transit    P.Auth     P.DAC     P.Accountable        A.Protect   A.Admin              A.NIS_DOMAINS  A.Bridges&Routers   Logica EVALUATION IN CONFIDENCE 7 38 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive The OSPs are derived from the [CAPP] and are included to indicate how the OSPs relate to the TOE security objectives and the primary non-IT security objectives. The OSPs are generally more abstract than the threats and so the correlation between similar threats and OSPs to objectives is not necessarily the same. The environmental objectives O.ADMIN, O.BOOT, O.INSTALL and O.CONSISTENCY are general objectives which are help counter all the threats (with the exception of T.TRANSIT in some cases) as follows: • O.ADMIN: Those responsible for administering the TOE must be competent and trustworthy in order to manage the security functions effectively. Effective management is necessary in order that the threats are not inadvertently or deliberately realised; • O.BOOT and O.INSTALL ensure that the correct copy of the operating system is installed and subsequently booted in a secure manner, and is hence relevant to help counter all the threats; • O.CONSISTENCY is required to ensure that data is set up and maintained in a consistent manner across all platforms in the distributed system. Erroneous or duplicate entries in the authentication information may allow any of the threats to be realised. 7.2 Security Objectives Rationale This section demonstrates that the security objectives stated in Section 4 above are traceable to all of the aspects identified in the TOE security environment and are suitable to cover them. 7.2.1 Complete Coverage - Threats This section provides evidence demonstrating coverage of the threats by both the IT and Non-IT security objectives. The table is followed by a discussion of the coverage for each threat. [T.ACCESS_INFO] An authorised user of the TOE accesses information without having permission from the person who owns, or is responsible for, the information. Security objective O.DAC counters this threat directly by ensuring the means are provided by which users can securely implement compartmentalisation of information in order to counter this threat. O.RESIDUAL_INFO helps counter the threat by ensuring that once an object has passed outside the control of DAC, that residual information contained in it is not passed to other users. Security objective O.AUTHORISATION supports O.DAC in countering this threat by ensuring that an authorised user cannot impersonate another authorised user, thereby undermining the intent of O.DAC. O.AUDIT helps counter this threat by ensuring that repeated [unsuccessful] attempts to access information to which the user is not granted permission, can be detected, thereby allowing the administrator to take action before the attack is successful. O.MANAGE and O.ENFORCEMENT counter this threat by ensuring: - privileged actions are controlled; and - the access controls cannot be bypassed. EVALUATION IN CONFIDENCE Logica 7 Rationale 39 Support is also provided by the following security objectives for the environment: a. O.ADMIN - to administer the controls over access to information; b. O.BOOT - to ensure that information cannot be accessed by booting an alternative operating system; c. O.AUTHDATA is require to protect the information which would otherwise enable attackers to gain access to the TOE; d. O.PROTECT - to ensure that data transmitted over network cabling is appropriately protected; e. O.RECOVER - to ensure that information cannot be accessed by terminating the operation of a server/workstation (whether intentional or not); f. O.SERIAL_LOGIN - to ensure that information is not seen by users who do not have a need to know when serial devices are being used; [T.ACCESS_TOE] An unauthorised user of the TOE gains access to the system, thereby gaining unauthorised access to information. O.AUTHORISATION ensures that all users identify themselves to the system, and that their claimed identity is authenticated before being granted access to the system. This therefore prevents unauthorised users gaining access to the system. O.AUDIT provides support in the form of auditing attempts to access the TOE. The auditing of unsuccessful attempts to login help to detect and hence counter the threat of repeated attacks on the access functions. O.MANAGE and O.ENFORCEMENT support this threat by ensuring: - the database of authorised users is properly managed and maintained; - the authorisation functions are always invoked and cannot be bypassed; - the auditing functions are set up appropriately to detect repeated attempts to login. Support is also provided by the following security objectives for the environment: a. O.ADMIN - to ensure that the introduction of new user identities is a restricted operation and performed only by the users responsible. b. O.ACCOUNTABLE - to ensure that unauthorised users are not provided with accounts enabling them to access the TOE; c. O.AUDITDATA - which ensures that bad passwords, which might be used to determine valid passwords, are not stored in the audit trail, and hence not known to any users. d. O.AUTHDATA - which ensures that valid authentication data is not disclosed to unauthorised individuals; e. O.CONSISTENCY - which ensures that access is granted to individuals on a basis consistent across all platforms. This avoids possible duplication of authentication data. [T.MODIFY] Unauthorised modification or destruction of information by an authorised user of the TOE. Logica EVALUATION IN CONFIDENCE 7 40 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive The security objective O.DAC provides the means to ensure that users can protect the integrity of the information they own or are responsible for. Security objective O.AUTHORISATION supports O.DAC in countering this threat by ensuring that an authorised user cannot impersonate another authorised user, thereby undermining the intent of O.DAC. O.AUDIT helps counter this threat by ensuring that repeated [unsuccessful] attempts to modify information to which the user is not granted permission, can be detected, thereby allowing the administrator to take action before the attack is successful. O.ENFORCEMENT supports this threat by ensuring the access control functions are always invoked and cannot be bypassed. Support is also provided by the following security objectives for the environment: a. O.INFO_PROTECT and O.PROTECT - ensures that information transmitted over the network is not accessible to other authorised users of the TOE and hence the data cannot be modified or destroyed; b. O.ADMIN ensures that the default access permissions are set appropriately so that access is granted, by default, to a restricted set of users. [T.ADMIN_RIGHTS] Unauthorised use of facilities which require administration rights by an authorised user of the TOE. O.AUTHORISATION ensures that only authorised users can access the TOE, and provides for identification of users to determine the administration right assigned to the user. O.AUDIT discourages the unauthorised use of administrator facilities by ensuring that any such breach of security policy can be detected. O.MANAGE and O.ENFORCEMENT support this threat by ensuring: - the database of authorised administrators is properly managed and maintained; - the administration functions are always checked when invoked and cannot be bypassed; - the auditing functions are set up appropriately to detect repeated attempts to use the administration functions by non-administrative users. O.AUTHDATA ensures user’s authentication data is kept secure. This prevents an authorised user impersonating an administrator to gain unauthorised access to administrator facilities. O.CONSISTENCY ensures that a single set of administration rights exist across the TOE, thereby avoiding errors caused by duplication or erroneous entries in the authorisation data. O.ACCOUNTABLE ensure that users are uniquely identified and the use of privileged facilities can be controlled amongst the user community. O.SOFTWARE_IN ensures that only administrators can introduce software into the TOE and hence counters the threat of malicious software being introduced. The introduction of some software e.g. compilers, may provide enhanced facilities to an attacker which could be used to mount a successful attack on the TOE and hence make unauthorised use of administration facilities. The following threats apply in environments where specific threats to distributed systems need to be countered. Typically such threats are countered by cryptographic or physical protection of network connections. EVALUATION IN CONFIDENCE Logica 7 Rationale 41 [T.TRANSIT] Data transferred between platforms is disclosed or modified to unauthorised users or processes either directly or indirectly (e.g. through spoofing of server/workstation identity). Administrators must ensure that data transferred between platforms i.e. along network cabling, is suitably protected against physical or other (e.g. tempest) attacks which may result in the disclose, modification or delay of information transmitted between platforms. Objective O.PROTECT ensures this is achieved. Because such issues need to be considered at installation time, objectives O.INSTALL and O.INFO_PROTECT are also applicable. 7.2.2 Complete Coverage - Policy This section provides evidence demonstrating coverage of the Organisational Security Policy by both the IT security objectives. The table is followed by a discussion of the coverage for each Security Policy. [P.AUTH] Only those users who have been authorised to access the information within the system may access the system. This policy is implemented through the objective O.AUTHROISATION which ensures that only authorised users are allowed access to the system. O.MANAGE and O.ENFORCEMENT support this policy by ensuring that the set of authorised users is effectively managed and that the authorisation functions are always invoked and cannot be bypassed. O.AUTHDATA supports this policy by ensuring that authorisation data is constructed in a manner commensurate with the protection required for the information on the TOE and that passwords are not disclosed since doing so would compromise the policy. [P.DAC] The right to access specific data objects is determined on the basis of: a. the owner of the object; and b. the identity of the subject attempting the access; and c. the implicit and explicit access rights to the object granted to the subject by the object owner. P.DAC is implemented through the objective O.DAC which provides the means of controlling access between objects and subjects on the attributes defined by the policy, and is supported by O.RESIDUAL_INFO objective which ensures that information will not given to users which do not have a need to know, when resources are reused. O.ENFORCEMENT supports this policy by ensuring that the access control functions are always invoked and cannot be bypassed. O.MANAGE supports this policy by requiring authorized administrator be able to manage the functions. [P.ACCOUNTABLE] The users of the system shall be held accountable for their actions within the system. Accountability is implemented primarily through the objective O.AUDIT which ensures uses’ security relevant events can be recorded so as to be able to hold users accountable for their actions. An unauthorised user can not be held accountable for their actions and O.AUTHORISATION therefore supports this policy by ensuring that only authorised users are allowed access. O.MANAGE and O.ENFORCEMENT Logica EVALUATION IN CONFIDENCE 7 42 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive support this policy by ensuring that an effective set of actions are audited in order to detect attempted breaches of the security policy and that the auditing functions are always invoked and cannot be bypassed. O.ADMIN, O.ACCOUNTABLE and O.AUDITDATA ensure that the administrator manages the auditing security functions effectively. 7.2.3 Complete Coverage - Environmental Assumptions This section provides evidence demonstrating coverage of the environmental assumptions by security objectives. The table is followed by a discussion of the coverage for each environmental assumption. [A.PROTECT] It is assumed that all network and peripheral cabling is 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. The environmental objective O.PROTECT ensures that network cabling is suitably protected against threats of modification, tampering or interruption of the data transmitted via this medium. O.INFO_PROTECT ensures that, where the cabling is carrying classified information, that the infrastructure has been approved. [A.ADMIN] It is assumed that there are one or more competent individuals who are assigned to manage the TOE and the security of the information it contains. Such personnel are assumed not to be careless, wilfully negligent or hostile. This assumption is met primarily by O.ADMIN, and supported by all the other environmental objectives which ensure that the administrative functions are performed in an manner effective in maintaining the security functions of the TOE. [A.NIS_DOMAINS] It is assumed that, if the product comprises more than one platform, all platforms are administered from a central point within each NIS+ domain. Note: NIS+ allows the creation of multiple administrative domains, thus allowing administrators to control local resources and user accounts, yet making it possible for users and resources to operate seamlessly over the entire organisation. NIS+ is installed and configured at installation time, and therefore objective O.CONSISTENCY ensures this assumption is upheld. [A.BRIDGES&ROUTERS] All bridges and routers are assumed to correctly pass data without modification. As for A.Protect, this assumptions is met by O.PROTECT and O.INFO_PROTECT; bridges and routers are part of the cabling infrastructure. 7.3 Security Requirements Rationale This section demonstrates that the set of security requirements is suitable to meet and is traceable to the set of security objectives. EVALUATION IN CONFIDENCE Logica 7 Rationale 43 7.3.1 Complete Coverage - Objectives This section demonstrates that the functional components selected for the TOE provide complete coverage of the defined security objectives. The mapping of components to security objectives is depicted in the following table. O.AUTHORISATION The TSF must ensure that only authorised users gain access to the TOE and its resources. Users authorised to access the TOE are defined using an identification and authentication process [CAPP, 5.3.5 and 5.3.3]. To ensure authorised access to the TOE, authentication data is protected [CAPP, 5.3.1, 5.3.4, 5.4.6]. The strength of the authentication mechanism must be sufficient to ensure unauthorised users cannot pose as authorised users with reasonable time, effort and other constraints [CAPP, 5.3.2]. Security Objective Functional Component O.AUTHORISATION 5.3.1 User Attribute Definition (FIA_ATD.1) 5.3.2 Strength of Authentication Data (FIA_SOS.1) 5.3.3 Authentication (FIA_UAU.1) 5.3.4 Protected Authentication Feedback (FIA_UAU.7) 5.3.5 Identification (FIA_UID.1) 5.4.6 Management of Authentication Data (FMT_MTD.1) O.DAC 5.2.1 Discretionary Access Control Policy (FDP_ACC.1) 5.2.2 Discretionary Access Control Functions (FDP_ACF.1) 5.3.1 User Attribute Definition (FIA_ATD.1) 5.3.6 User-Subject Binding (FIA_USB.1) 5.4.1 Management of Object Security Attributes (FMT_MSA.1) 5.4.2 Static Attribute Initialization (FMT_MSA.3) 5.4.8 Revocation of Object Attributes (FMT_REV.1) O.AUDIT 5.1.1 Audit Data Generation (FAU_GEN.1) 5.1.2 User Identity Generation (FAU_GEN.2) 5.1.3 Audit Review (FAU_SAR.1) 5.1.4 Restricted Audit Review (FAU_SAR.2) 5.1.5 Selectable Audit Review (FAU_SAR.3) 5.1.6 Selective Audit (FAU_SEL.1) 5.1.7 Guarantees of Audit Data Availability (FAU_STG.1) 5.1.8 Action in Case of Possible Audit Data Loss (FAU_STG.3) 5.1.9 Prevention of Audit Data Loss (FAU_STG.4) 5.3.6 User-Subject Binding (FIA_USB.1) 5.4.3 Management of the Audit Trail (FMT_MTD.1) 5.4.4 Management of Audited Events (FMT_MTD.1) 5.5.4 Reliable Time Stamps (FPT_STM.1) O.RESIDUAL_INFO 5.2.3 Object Residual Information Protection (Note.1) 5.2.4 Subject Residual Information Protection (FDP_RIP.2) O.MANAGE 5.1.3 Audit Review (FAU_SAR.1) 5.1.5 Selectable Audit Review (FAU_SAR.3) 5.1.6 Selective Audit (FAU_SEL.1) 5.1.8 Action in Case of Possible Audit Data Loss (FAU_STG.3) 5.1.9 Prevention of Audit Data Loss (FAU_STG.4) 5.4.3 Management of the Audit Trail (FMT_MTD.1) 5.4.4 Management of Audited Events (FMT_MTD.1) 5.4.5 Management of User Attributes (FMT_MSA.1) 5.4.6 Management of Authentication Data (FMT_MTD.1) 5.4.7 Revocation of User Attributes (FMT_REV.1) 5.4.9 Security Management Roles (FMT_SMR.1) O.ENFORCEMENT 5.5.1 Abstract Machine Testing (FPT_AMT.1) 5.5.2 Reference Mediation (FPT_RVM.1) 5.5.3 Domain Separation (FPT_SEP.1) Logica EVALUATION IN CONFIDENCE 7 44 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive O.DAC The TSF must provide its users with the means of controlling and limiting access to the objects and resources they own or are responsible for, on the basis of individual users or identified groups of users, and in accordance with the set of rules defined by the P.DAC security policy. Discretionary access control must have a defined scope of control [CAPP, 5.2.1]. The rules of the DAC policy must be defined [CAPP, 5.2.2]. The security attributes of objects used to enforce the DAC policy must be defined [CAPP, 5.2.2]. The security attributes of subjects used to enforce the DAC policy must be defined [CAPP, 5.3.1 and 5.3.6]. Authorised users must be able to control who has access to objects [CAPP, 5.4.1] and be able to revoke that access [CAPP, 5.4.8]. Protection of named objects must be continuous, starting from object creation [CAPP, 5.4.2]. O.AUDIT The TOE must provide the means of recording any security relevant events, so as to (a) assist an administrator in the detection of potential attacks or misconfiguration of the TOE security features that would leave the TOE susceptible to attack; and (b) hold users accountable for any actions they perform that are relevant to security. Security-relevant actions must be defined, auditable [CAPP, 5.1.1], and capable of being associated with individual users [CAPP, 5.1.2 and 5.3.6]. The audit trail must be protected so that only authorized users may access it [CAPP, 5.1.4]. The TSF must provide the capability to audit the actions of an individual user [CAPP, 5.1.5, 5.1.6 and 5.3.6]. The audit trail must be complete [CAPP, 5.1.7 and 5.1.9]. The time stamp associated must be reliable [CAPP, 5.5.4]. An authorised administrator must be able to review [CAPP, 5.1.3] and manage [CAPP, 5.1.8, 5.4.3 and 5.4.4] the audit trail. EVALUATION IN CONFIDENCE Logica 7 Rationale 45 O.RESIDUAL_INFO The TSF must ensure that any information contained in a protected resource is not released when the resource is recycled. Residual information associated with defined objects in the TOE must be purged prior to the reuse of the object containing the residual information [CAPP, 5.2.3, 5.3.4]. O.MANAGE The TSF must allow administrators to effectively manage the TOE and its security functions, and must ensure that only authorised administrators are able to access such functionality. The TSF must provide for an authorised administrator to manage the TOE [CAPP, 5.4.9]. The administrator must be able to administer user accounts [CAPP, 5.4.5, 5.4.6, 5.4.7]. The administrator must be able to review manage the audit trail [CAPP, 5.1.3, 5.1.5, 5.1.6, 5.1.8, 5.1.9, 5.4.3 and 5.4.4]. O.ENFORCEMENT The TOE security policy is enforced in a manner which ensures that the organisational policies are enforced in the target environment i.e. the integrity of the TSF is protected. The TSF must make and enforce the decisions of the TSP [CAPP, 5.5.2]. It must be protected from interference that would prevent it from performing its functions [CAPP, 5.5.3]. Additionally, the TOE must provide the capability to demonstrate correct operation of the TSF's underlying abstract machine [CAPP, 5.5.1]. The correctness of this objective is further met through the assurance requirements defined in the PP. This objective provides global support to other security objectives for the TOE by protecting the parts of the TOE which implement policies and ensures that policies are enforced. Logica EVALUATION IN CONFIDENCE 7 46 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive 7.3.2 Requirements are Mutually Supportive and Internally Consistent All dependencies are satisfied. The key to the symbols used are: x required dependency i inferred dependency o optional dependency (there may be cases where one of two or more optional dependencies are required) ? inferred, optional, dependency The above correlation is taken directly from [CAPP] with corrections where [CAPP] is incorrect. The set of IT security requirements for the TOE are the same as those for [CAPP] and hence the above table taken from [CAPP] is appropriate, and the justification in [CAPP, 7.2.1] applies to show that the TOE has IT security requirements that together form a mutually supportive and internally consistent whole. For the IT environment, the FMT_MOF.1 direct dependency on FMT_SMR.1 and indirect dependency on FIA_UID.1 does not need to be satisfied because the IT environment is not required to maintain any record of roles and who may assume them. FAU_GEN.1 FAU_SAR.1 FAU_STG.1 FDP_ACC.1 FDP_ACF.1 FDP_IFC.1 FDP_IFF.1 FIA_ATD.1 FIA_UAU.1 FIA_UID.1 FMT_MSA.1 FMT_MSA.3 FMT_MTD.1 FMT_SMR.1 FPT_STM.1 FAU_GEN.1 x FAU_GEN.2 x x i FAU_SAR.1 x i FAU_SAR.2 i x i FAU_SAR.3 i x i FAU_SEL.1 x i x i i FAU_STG.1 x i FAU_STG.3 i x i FAU_STG.4 x i FDP_ACC.1 i x i i i i FDP_ACF.1 x i i i x i FDP_RIP.2 Note 1 FIA_ATD.1 FIA_SOS.1 FIA_UAU.1 x FIA_UAU.7 x i FIA_UID.1 FIA_USB.1 x FMT_MSA.1 o ? o ? i x FMT_MSA.3 ? ? ? ? i x x FMT_MTD.1 i x FMT_REV.1 i x FMT_SMR.1 x FPT_AMT.1 FPT_RVM.1 FPT_SEP.1 FPT_STM.1 EVALUATION IN CONFIDENCE Logica 7 Rationale 47 It only needs to determine whether the correct password was supplied. The password mechanism is used to distinguish between roles. In a sense, the dependant SFRs are all wrapped up in this single SFR. 7.3.3 Justification for Choice of Assurance Requirements This security target has been based largely on [CAPP]. It specifies security requirements for a product which is to be used in an environment with a moderate level of risk to the assets. In such environments, an assurance level of at least EAL3 is recommended as stated in [CAPP]. This security target claims an assurance level of EAL4, which also meets these requirements. 7.3.4 Strength of Function Claim is Consistent with Security Objectives The claimed strength of function rating is SOF-medium. This is consistent with [CAPP] which states that a ‘one off’ probability of guessing the password shall be 1,000,000. This is specified in SFR FIA_SOS.1 which is in turn consistent with the security objectives described in section 7.3. 7.4 TOE Summary Specification Rationale This section demonstrates that the TOE security functions and assurance measures are suitable to meet the TOE security requirements. 7.4.1 IT Security Functions Satisfy Functional Requirements This section demonstrates that the combination of the specified TOE IT security functions work together so as to satisfy the TOE security functional requirements. The table below shows the TOE security functions which together satisfy each security functional requirement. They are grouped under the relevant TOE security objective. Security Functional Requirement TOE Security Function(s) Audit Data Generation (FAU_GEN.1.1) Audit.1 to Audit.11, Audit.15a Audit Data Generation (FAU_GEN.1.2) Audit.1,2,3,4,5,6,8,11,21 User Identity Association (FAU_GEN.2.1) Audit.1 to Audit.11 Audit Review (FAU_SAR.1.1) Audit.19 Audit Review (FAU_SAR.1.2) Audit.19 Restricted Audit Review (FAU_SAR.2.1) Audit.14 Selectable Audit Review (FAU_SAR.3.1) Audit.19 Selective Audit (FAU_SEL.1.1) Audit.17, Audit.18 Protected Audit Trail Storage (FAU_STG.1.1) Audit.14 Table 5: SFR - IT SF Mapping Logica EVALUATION IN CONFIDENCE 7 48 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive Protected Audit Trail Storage (FAU_STG.1.2) Audit.14 Action in Case of Possible Audit Data Loss (FAU_STG.3.1) Audit.23 Prevention of Audit Data Loss (FAU_STG.4.1) Audit.20, Audit.21 Discretionary Access Control Policy (FDP_ACC.1.1) DAC.6 Discretionary Access Control Functions (FDP_ACF.1.1) DAC.3, DAC.4 Discretionary Access Control Functions (FDP_ACF.1.2) DAC.6 Discretionary Access Control Functions (FDP_ACF.1.3) DAC.8 Discretionary Access Control Functions (FDP_ACF.1.4) DAC.3, DAC.4, DAC.6. Object Residual Information Protection (FDP_RIP.2.1) OR.1, OR.2, OR.3 Subject Residual Information Protection (Note 1) OR.1, OR.2, OR.3 User Attribute Definition (FIA_ATD.1.1) IA.11 Strength of Authentication Data (FIA_SOS.1.1) IA.1, IA.11b Authentication (FIA_UAU.1.1) IA.1 Authentication (FIA_UAU.1.2) IA.1 Protected Authentication Feedback (FIA_UAU.7.1) IA.9 Identification (FIA_UID.1.1) IA.1 Identification (FIA_UID.1.2) IA.1 User-Subject Binding (FIA_USB.1.1;1) IA.2c User-Subject Binding (FIA_USB.1.1;2) IA.2c User-Subject Binding (FIA_USB.1.1;3) IA.2c Management of Object Security Attributes (FMT_MSA.1.1;1) DAC.1, DAC.2 Static Attribute Initialization (FMT_MSA.3.1) DAC.7c Static Attribute Initialization (FMT_MSA.3.2) DAC.3, DAC.4, DAC.7c Management of the Audit Trail (FMT_MTD.1.1;1) Audit.14 Management of Audited Events (FMT_MTD.1.1;2) Audit.16, 17, 18 Management of User Attributes (FMT_MTD.1.1;3) IA.11 Management of Authentication Data (FMT_MTD.1.1;4) IA.11 Security Functional Requirement TOE Security Function(s) Table 5: SFR - IT SF Mapping EVALUATION IN CONFIDENCE Logica 7 Rationale 49 7.4.2 Justification for Compliance of Assurance Measures Section 6.3 shows that all assurance requirements are met by an appropriate assurance measure. 7.5 PP Claims and Rationale 7.5.1 PP Reference The TOE meets all of the requirements of the Controlled Access Protection Profile, which is defined in [CAPP]. 7.5.2 PP Tailoring The security functional requirements for the TOE are as defined in [CAPP] with refinements as necessary and appropriate for a Security Target. These refinements are detailed in section 5.1.2. Management of Authentication Data (FMT_MTD.1.1;5) IA.10, IA.11 Revocation of User Attributes (FMT_REV.1.1;1) IA.11 Revocation of User Attributes (FMT_REV.1.1;2) DAC.1, DAC.2 Revocation of Object Attributes (FMT_REV.1.2;1) IA.11 Revocation of Object Attributes (FMT_REV.1.2;2) DAC.6 Security Management Roles (FMT_SMR.1.1) DAC.1, DAC.2, IA.11 Security Management Roles (FMT_SMR.1.2) DAC.2, DAC.8, IA.11, Audit.14, 16, 17, 18, 19, 22, 23 Abstract Machine Testing (FPT_AMT.1.1) ENF.3 Reference Mediation (FPT_RVM.1.1) ENF.1 Domain Separation (FPT_SEP.1.1) ENF.2 Domain Separation (FPT_SEP.1.2) ENF.2 Reliable Time Stamps (FPT_STM.1.1) Audit.12 a. FAU_GEN.1.1 implicitly includes the requirement not to store password infor- mation in the audit trail as required by IT SF Audit.15. b. Supplying a new password is stated in ITSF IA.11, and it is the process through which a user enters a new password that enforces the construction of the password and hence the probability of guessing the correct password. c. Effective User IDs and Group IDs also exist as noted in 6.1.1 Security Functional Requirement TOE Security Function(s) Table 5: SFR - IT SF Mapping Logica EVALUATION IN CONFIDENCE 7 50 Solaris 8 2/02 Security Target, 19 March 2003, 1.0 Definitive 7.5.3 PP Additions There are no additional security functional requirements for the TOE beyond that defined in [CAPP]. There is one additional security requirement for the IT environment which is detailed in section 5.4. This relates to the requirements placed on the SC or OpenBoot PROM in support of protecting the server/workstation in the environment. There are no additional TOE security objectives to those contained in [CAPP]. The security objectives for the TOE environment in this security target may be regarded as additional to those contained in [CAPP], although they are deemed to be broadly equivalent, and refined due to the specific environment assumed for the Solaris 8 2/02 product. 7.5.4 PP Rationale The objectives used in this Security Target are derived from [CAPP]. The differences are minor and result from refinements appropriate to a Security Target where a specific product and the assumed environment are being described. The SFRs used in this Security Target are derived from [CAPP], and have been refined as required for inclusion in a Security Target. The rationale presented in this document describing why the SFRs are appropriate to meet the security objectives has been taken from [CAPP] also. Because of the similarities between the objectives and SFRs contained in this Security Target and in [CAPP], the justification provided in [CAPP] is also appropriate for this Security Target.