Certification Report
Bundesamt für Sicherheit in der Informationstechnik
BSI-DSZ-CC-0427-2007
for
Oracle Enterprise Linux
Version 4 Update 4
from
Oracle Corporation UK Limited
BSI - Bundesamt für Sicherheit in der Informationstechnik, Postfach 20 03 63, D-53133 Bonn
Phone +49 (0)3018 9582-0, Fax +49 (0)3018 9582-5477, Infoline +49 (0)3018 9582-111
Certification Report V1.0 ZS-01-01-F-326 V3.4
BSI-DSZ-CC-0427-2007
Oracle Enterprise Linux
Version 4 Update 4
from
Oracle Corporation UK Limited
Common Criteria Arrangement
The IT product identified in this certificate has been evaluated at an accredited and licensed/
approved evaluation facility using the Common Methodology for IT Security Evaluation, version 2.3
(ISO/IEC 15408:2005) for conformance to the Common Criteria for IT Security Evaluation, version
2.3 (ISO/IEC 15408:2005).
Evaluation Results:
PP Conformance: Controlled Access Protection Profile (CAPP), Issue 1.d, 08.10.1999
Functionality: PP conformant plus product specific extensions
Common Criteria Part 2 extended
Assurance Package: Common Criteria Part 3 conformant
EAL4 augmented by
ALC_FLR.3 – Systematic flaw remediation
This certificate applies only to the specific version and release of the product in its evaluated
configuration and in conjunction with the complete Certification Report.
The evaluation has been conducted in accordance with the provisions of the certification scheme
of the German Federal Office for Information Security (BSI) and the conclusions of the evaluation
facility in the evaluation technical report are consistent with the evidence adduced.
The notes mentioned on the reverse side are part of this certificate.
Bonn, 19. July 2007
The President of the Federal Office
for Information Security
Dr. Helmbrecht L.S.
Bundesamt für Sicherheit in der Informationstechnik
Godesberger Allee 185-189 - D-53175 Bonn - Postfach 20 03 63 - D-53133 Bonn
Phone +49 (0)3018 9582-0, Fax +49 (0)3018 9582-5477, Infoline +49 (0)3018 9582-111
The rating of the strength of functions does not include the cryptoalgorithms suitable for encryption
and decryption (see BSIG Section 4, Para. 3, Clause 2)
This certificate is not an endorsement of the IT product by the Federal Office for Information
Security or any other organisation that recognises or gives effect to this certificate, and no warranty
of the IT product by the Federal Office for Information Security or any other organisation that
recognises or gives effect to this certificate, is either expressed or implied.
BSI-DSZ-CC-0427-2007 Certification Report
Preliminary Remarks
Under the BSIG1
Act, the Federal Office for Information Security (BSI) has the
task of issuing certificates for information technology products.
Certification of a product is carried out on the instigation of the vendor or a
distributor, hereinafter called the sponsor.
A part of the procedure is the technical examination (evaluation) of the product
according to the security criteria published by the BSI or generally recognised
security criteria.
The evaluation is normally carried out by an evaluation facility recognised by the
BSI or by BSI itself.
The result of the certification procedure is the present Certification Report. This
report contains among others the certificate (summarised assessment) and the
detailed Certification Results.
The Certification Results contain the technical description of the security
functionality of the certified product, the details of the evaluation (strength and
weaknesses) and instructions for the user.
1
Act setting up the Federal Office for Information Security (BSI-Errichtungsgesetz, BSIG) of
17 December 1990, Bundesgesetzblatt I p. 2834
V
Certification Report BSI-DSZ-CC-0427-2007
VI
Contents
Part A: Certification
Part B: Certification Results
Part C: Excerpts from the Criteria
BSI-DSZ-CC-0427-2007 Certification Report
A Certification
1 Specifications of the Certification Procedure
The certification body conducts the procedure according to the criteria laid down
in the following:
• BSIG2
• BSI Certification Ordinance3
• BSI Schedule of Costs4
• Special decrees issued by the Bundesministerium des Innern (Federal
Ministry of the Interior)
• DIN EN 45011 standard
• BSI certification: Procedural Description (BSI 7125)
• Common Criteria for IT Security Evaluation (CC), version 2.35
• Common Methodology for IT Security Evaluation (CEM), version 2.3
• BSI certification: Application Notes and Interpretation of the Scheme (AIS)
• Advice from the Certification Body on methodology for assurance
components above EAL4 (AIS 34)
2
Act setting up the Federal Office for Information Security (BSI-Errichtungsgesetz, BSIG) of
17 December 1990, Bundesgesetzblatt I p. 2834
3
Ordinance on the Procedure for Issuance of a Certificate by the Federal Office for
Information Security (BSI-Zertifizierungsverordnung, BSIZertV) of 07 July 1992,
Bundesgesetzblatt I p. 1230
4
Schedule of Cost for Official Procedures of the Bundesamt für Sicherheit in der
Informationstechnik (BSI-Kostenverordnung, BSI-KostV) of 03 March 2005,
Bundesgesetzblatt I p. 519
5
Proclamation of the Bundesministerium des Innern of 10 May 2006 in the Bundesanzeiger
dated 19 May 2006, p. 3730
A-1
Certification Report BSI-DSZ-CC-0427-2007
2 Recognition Agreements
In order to avoid multiple certification of the same product in different countries
a mutual recognition of IT security certificates - as far as such certificates are
based on ITSEC or CC - under certain conditions was agreed.
2.1 European Recognition of ITSEC/CC - Certificates
The SOGIS-Agreement on the mutual recognition of certificates based on
ITSEC became effective in March 1998. This agreement has been signed by
the national bodies of Finland, France, Germany, Greece, Italy, The
Netherlands, Norway, Portugal, Spain, Sweden, Switzerland and the United
Kingdom. This agreement on the mutual recognition of IT security certificates
was extended to include certificates based on the CC for all evaluation levels
(EAL 1 – EAL 7). The German Federal Office for Information Security (BSI)
recognizes certificates issued by the national certification bodies of France and
the United Kingdom within the terms of this Agreement.
2.2 International Recognition of CC - Certificates
An arrangement (Common Criteria Arrangement) on the mutual recognition of
certificates based on the CC evaluation assurance levels up to and including
EAL 4 has been signed in May 2000 (CC-MRA). It includes also the recognition
of Protection Profiles based on the CC. As of February 2007 the arrangement
has been signed by the national bodies of:
Australia, Austria, Canada, Czech Republic, Denmark, Finland, France,
Germany, Greece, Hungary, India, Israel, Italy, Japan, Republic of Korea, The
Netherlands, New Zealand, Norway, Republic of Singapore, Spain, Sweden,
Turkey, United Kingdom, United States of America.
The current list of signatory nations resp. approved certification schemes can be
seen on the web site: http:\\www.commoncriteriaportal.org
A-2
BSI-DSZ-CC-0427-2007 Certification Report
3 Performance of Evaluation and Certification
The certification body monitors each individual evaluation to ensure a uniform
procedure, a uniform interpretation of the criteria and uniform ratings.
The product Oracle Enterprise Linux Version 4 Update 4 has undergone the
certification procedure at BSI.
The evaluation of the product Oracle Enterprise Linux Version 4 Update 4 was
conducted by atsec information security GmbH. The atsec information security
GmbH is an evaluation facility (ITSEF)6
recognised by BSI.
The sponso, vendor and distributor is:
Oracle Corporation UK Limited
520 Oracle Parkway, Thames Valley Park
Reading, Berkshire, RG6 1RA, UK
The certification is concluded with
• the comparability check and
• the production of this Certification Report.
This work was completed by the BSI on 19. July 2007.
The confirmed assurance package is only valid on the condition that
• all stipulations regarding generation, configuration and operation, as given
in the following report, are observed,
• the product is operated in the environment described, where specified in the
following report.
This Certification Report only applies to the version of the product indicated
here. The validity can be extended to new versions and releases of the product,
provided the sponsor applies for re-certification of the modified product, in
accordance with the procedural requirements, and the evaluation does not
reveal any security deficiencies.
For the meaning of the assurance levels and the confirmed strength of
functions, please refer to the excerpts from the criteria at the end of the
Certification Report.
6
Information Technology Security Evaluation Facility
A-3
Certification Report BSI-DSZ-CC-0427-2007
A-4
4 Publication
The following Certification Results contain pages B-1 to B-30.
The product Oracle Enterprise Linux Version 4 Update 4 has been included in
the BSI list of the certified products, which is published regularly (see also
Internet: http://www.bsi.bund.de). Further information can be obtained from BSI-
Infoline +49 228 9582-111.
Further copies of this Certification Report can be requested from the vendor7
of
the product. The Certification Report can also be downloaded from the above-
mentioned website.
7
Oracle Corporation UK Limited
520 Oracle Parkway, Thames Valley Park
Reading, Berkshire, RG6 1RA, UK
BSI-DSZ-CC-0427-2007 Certification Report
B Certification Results
The following results represent a summary of
• the security target of the sponsor for the target of evaluation,
• the relevant evaluation results from the evaluation facility, and
• complementary notes and stipulations of the certification body.
B-1
Certification Report BSI-DSZ-CC-0427-2007
Contents of the certification results
1 Executive Summary 3
2 Identification of the TOE 14
3 Security Policy 15
4 Assumptions and Clarification of Scope 16
5 Architectural Information 18
6 Documentation 22
7 IT Product Testing 23
8 Evaluated Configuration 24
9 Results of the Evaluation 25
10 Comments/Recommendations 27
11 Annexes 27
12 Security Target 27
13 Definitions 27
14 Bibliography 29
B-2
BSI-DSZ-CC-0427-2007 Certification Report
1 Executive Summary
The Target of Evaluation (TOE) is the operating system Oracle Enterprise Linux
Version 4 Update 4 (with the capp-eal4-config-oracle package).
The TOE is a general purpose, multi-user, multi-tasking Linux based operating
system. It provides a platform for a variety of applications in the governmental
and commercial environment. It is available on a broad range of computer
systems, ranging from departmental servers to multi-processor enterprise
servers.
The evaluation covers a potentially distributed, but closed network of servers
running the evaluated version of the TOE. The hardware platforms selected for
the evaluation consist of machines which are available when the evaluation has
completed and to remain available for a substantial period of time afterwards.
The TOE includes software components only and provides CAPP compliant
security functionality plus product specific extentions. Among these functions
are:
• Identification and Authentication
• Discretionary Access Control
• Secure Communication
• Audit
• Object reuse functionality
• Security Management
• TSF Protection
The evaluated version of the TOE can be run on Dell PowerEdge 1850
(EM64T) and HP ProLiant DL380 G5 (EM64T). For a detailed description of the
system the tests were performed on, please refer to chapter 7 of this report.
The product Oracle Enterprise Linux Version 4 Update 4 is delivered by Oracle
Corporation UK Limited via electronic download. It contains a set of ISO CD
images and additional software packages as listed in chapter 2 of this report.
The additional packages contain the Evaluated Configuration Guide, updates to
fix problems and scripts that can be used for the secure installation process.
The user needs to verify the integrity and authenticity of the downloaded
software before installing the TOE.
For a detailed listing of the software packages that are part of the TOE please
refer to chapter 2 of this report.
For a detailed listing of guidance documents to be followed by a user of the
TOE refer to chapter 6 of this report.
The IT product Oracle Enterprise Linux Version 4 Update 4 (with the capp-eal4-
config-oracle package) was evaluated by atsec information security GmbH. The
B-3
Certification Report BSI-DSZ-CC-0427-2007
evaluation was completed on 13. July 2007. The atsec information security
GmbH is an evaluation facility (ITSEF)8
recognised by BSI.
The sponsor, vendor and distributor is
Oracle Corporation UK Limited
520 Oracle Parkway, Thames Valley Park
Reading, Berkshire, RG6 1RA, UK
1.1 Assurance package
The TOE security assurance requirements are based entirely on the assurance
components defined in part 3 of the Common Criteria (see Annex C or [1], part
3 for details). The TOE meets the assurance requirements of assurance level
EAL4 (Evaluation Assurance Level 4 augmented). The following table shows
the augmented assurance components.
Requirement Identifier
EAL4 TOE evaluation: methodically designed, tested, and reviewed
+: ALC_FLR.3 Life cycle support – Systematic flaw remediation
Table 1: Assurance components and EAL-augmentation
1.2 Functionality
The TOE Security Functional Requirements (SFR) selected in the Security
Target are Common Criteria Part 2 extended as shown in the following tables.
The following SFRs are taken from CC part 2:
Security Functional
Requirement
Addressed issue
FAU Security audit
FAU_GEN.1 Audit Data Generation
FAU_GEN.2 User Identity Association
FAU_SAR.1 Audit Review
FAU_SAR.2 Restricted Audit Review
FAU_SAR.3 Selectable Audit Review
FAU_SEL.1 Selective Audit
FAU_STG.1 Guarantees of Audit Data Availability
FAU_STG.3 Action in Case of Possible Audit Data Loss
FAU_STG.4 Prevention of Audit Data Loss
8
Information Technology Security Evaluation Facility
B-4
BSI-DSZ-CC-0427-2007 Certification Report
Security Functional
Requirement
Addressed issue
FCS Cryptographic support
FCS_CKM.1(1) Cryptographic key generation (SSL: Symmetric
algorithms)
FCS_CKM.1(2) Cryptographic key generation (SSH: Symmetric
algorithms)
FCS_CKM.1(3) Cryptographic key generation (SSL: RSA)
FCS_CKM.2(1) Cryptographic key distribution (SSL: RSA public keys)
FCS_CKM.2(2) Cryptographic key distribution (SSH: DiffieHellman key
negotiation)
FCS_CKM.2(3) Cryptographic key distribution (SSH: DSS public keys)
FCS_CKM.2(4) Cryptographic key distribution (SSL: Symmetric keys)
FCS_COP.1(1) Cryptographic operation (SSL: RSA)
FCS_COP.1(2) Cryptographic operation (SSL: Symmetric operations)
FCS_COP.1(3) Cryptographic operation (SSH: Symmetric operations)
FDP User data protection
FDP_ACC.1 Discretionary Access Control Policy
FDP_ACF.1 Discretionary Access Control Functions
FDP_RIP.2 Object Residual Information Protection
FDP_UCT.1 Basic data exchange confidentiality
FDP_UIT.1 Data exchange integrity
FIA Identification and authentication
FIA_ATD.1 User Attribute Definition
FIA_SOS.1 Strength of Authentication Data
FIA_UAU.2 Authentication
FIA_UAU.7 Protected Authentication Feedback
FIA_UID.2 Identification
FIA_USB.1 User Subject Binding
FMT Security Management
FMT_MSA.1 Management of Object Security Attributes
FMT_MSA.2 Secure security attributes
FMT_MSA.3 Static Attribute Initialization
FMT_MTD.1 Management of the Audit Trail
FMT_MTD.1 Management of Audited Events
FMT_MTD.1 Management of User Attributes
FMT_MTD.1 Management of Authentication Data
B-5
Certification Report BSI-DSZ-CC-0427-2007
Security Functional
Requirement
Addressed issue
FMT_REV.1 Revocation of User Attributes
FMT_REV.1 Revocation of Object Attributes
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security Management Roles
FPT Protection of the TOE Security Functions
FPT_AMT.1 Abstract Machine Testing
FPT_RVM.1 Reference Mediation
FPT_SEP.1 Domain Separation
FPT_STM.1 Reliable Time Stamps
FTP Truted path/channels
FTP_ITC.1 Inter-TSF trusted channel
Table 2: SFRs for the TOE taken from CC Part 2
The following CC part 2 extended SFRs are defined:
Security Functional
Requirement
Addressed issue
FDP User data protection
Note 1 Subject Residual Information Protection
Table 3: SFRs for the TOE, CC part 2 extended
Note: only the titles of the Security Functional Requirements are provided. For
more details and application notes please refer to the ST chapter 5.1.
The following Security Functional Requirements are defined for the IT-
Environment of the TOE:
Security Functional
Requirement
Addressed issue
FDP User data protection
FDP_ACC.1 Subset access control
FDP_ACF.1 Security attribute based access control
FMT Security Management
FMT_MSA.3 Static attribute initialisation
Table 4: SFRs for the IT-Environment
Note: only the titles of the Security Functional Requirements are provided. For
more details and application notes please refer to the ST chapter 5.3.
These Security Functional Requirements are implemented by the TOE Security
Functions:
B-6
BSI-DSZ-CC-0427-2007 Certification Report
TOE Security Function Addressed issue
Identification and Authentication (IA)
IA.1 User Identification and Authentication Data
Management
IA.2 Common Authentication Mechanism
IA.3 Interactive Login and Related Mechanisms
IA.4 User Identity Changing
IA.5 Login Processing
Audit (AU)
AU.1 Audit Configuration
AU.2 Audit Processing
AU.3 Audit Record Format
AU.4 Audit Post-Processing
Discretionary Access Control (DA)
DA.1 General DAC Policy
DA.2 Permission Bits
DA.3 Access Control Lists
DA.4 Discretionary Access Control: IPC Objects
Object Reuse (OR)
OR.1 Object Reuse: File System Objects
OR.2 Object Reuse: IPC Objects
OR.4 Object Reuse: Memory Objects
Security Management (SM)
SM.1 Roles
SM.2 Access Control Configuration and Management
SM.3 Management of User, Group and Authentication Data
SM.4 Management of Audit Configuration
SM.5 Reliable Time Stamps
Secure Communication (SC)
SC.1 Secure Protocols
TSF Protection (TP)
TP.1 TSF Invocation Guarantees
TP.2 Kernel
TP.3 Kernel Modules
TP.4 Trusted Processes
TP.5 TSF Databases
B-7
Certification Report BSI-DSZ-CC-0427-2007
TOE Security Function Addressed issue
TP.6 Internal TOE Protection Mechanisms
TP.7 Testing the TOE Protection Mechanisms
Table 5: Security Functions
Please note that only the titles of the Security Functions have been provided
here. For more details please refer to the Security Target [6], chapter 6.2.
1.3 Strength of Function
The TOE’s strength of functions is claimed ‘medium’ (SOF-medium) for specific
functions as indicated in the Security Target [6], chapter 6.5.
The rating of the strength of functions does not include the cryptoalgorithms
suitable for encryption and decryption (see BSIG Section 4, Para. 3, Clause 2).
For details see chapter 9 of this report.
1.4 Summary of threats and Organisational Security Policies
(OSPs) addressed by the evaluated IT product
The TOE has to avert the following threats. They are cited from the Security
Target [6], chapter 3.2.1:
Threats Addressed issue
T.UAUSER An attacker (possibly, but not necessarily, an
unauthorized user of the TOE) may impersonate an
authorized user of the TOE. This includes the threat of
an authorized user that tries to impersonate as another
authorized user without knowing the authentication
information.
T.UAACCESS An authorized user of the TOE may access information
resources without having permission from the person
who owns, or is responsible for, the information
resource for the type of access.
T.COMPROT An attacker (possibly, but not necessarily, an
unauthorized user of the TOE) may intercept a
communication link between the TOE and another
trusted IT product to intercept or modify information
transferred between the TOE and the other trusted IT
product (which may be another instantiation of the TOE)
using defined protocols (SSH or SSL) in a way that can
not be detected by the TOE or the other trusted IT
product.
Table 6: Threats addressed by the TOE
The TOE has to comply to the following Organisational Security Policies
(OSPs). They are defined in the Security Target [6], chapter 3.3 and
summarised here:
B-8
BSI-DSZ-CC-0427-2007 Certification Report
Organisational Security Policy Addressed issue
P.AUTHORISED_USERS Only users who have been authorised to access
information within the system may access the system.
P.NEED_TO_KNOW The organisation using the TOE must define a
discretionary access control policy on a need-to-know
basis. The rules of this access control policy should be
based on the attributes (i) owner of object, (ii) identity of
subject attempting access to an object and (iii) access
rights (of a subject for the accessed object).
P.ACCOUNTABILITY The users of the system shall be held accountable for
their actions.
Table 7: Organisational Security Policies defined in the ST
1.5 Special configuration requirements
The configuration requirements for the TOE are defined in chapter 2.4 and
subsequent chapters of the Security Target [6] and are summarised here
(please refer to the Security Target for the precise and more detailed
description):
• The CC evaluated package set must be selected at install time in
accordance with the description provided in the Evaluated Configuration
Guide and installed accordingly.
• The operating system supports the use of IPv4 and IPv6, only IPv4 is
included within the TOE.
• Both installation from CD and installation from a defined disk partition are
supported.
• The default configuration for identification and authentication are the
defined password based PAM modules. 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 connected directly to the system
and afforded the same physical protection as the server.
• The TOE comprises a single server machine (and optional peripherals) as
listed in section 2.4.2 of the Security Target [6] running the system software
listed in the package list in section 2.3 of the ST (a server running the above
listed software is referred to as a “TOE server” in the following).
The evaluated configuration supports multiple following file system types.
• Filesystems using physical media (hard disk, CD-ROM or DVD-ROM):
• ext3 journaling filesystem,
• ocfs2, the Oracle Cluster File System,
B-9
Certification Report BSI-DSZ-CC-0427-2007
• the read-only ISO 9660 filesystem for CD-ROM and DVD-ROM drives,
• RAM based nonpersistent file systems:
• The temporary filesystem (tmpfs) used as a temporary RAM based file
system. This file system is not persistent across boots of the operating
system,
• dlmfs, the Distributed Lock Manager File System
• Pseudo file systems that are used as configuration or monitoring interfaces
to the kernel in a running system, and that do not support arbitrary data
storage:
• 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. Additional restrictions apply for
specific objects in this file system.
• The sysfs filesystem (sysfs) used to export and handle non-process
related kernel information such as driver specific information. Access to
objects there can be restricted using the DAC mechanism (which are
the permission bits only).
• The kernel configuration filesystem (configfs) which supports an
administrative interface to kernel data objects.
• The pseudo terminal device file system (devpts) used to provide pseudo
terminal support.
• The miscellaneous binary file format registration file system (binfmt_misc)
used to configure interpreters for executing binary files based on file header
information. For example, this enables direct execution of Java files using
the execve system call instead of the traditional invocation of the java
interpreter with the Java file provided as an argument.
• The virtual root file system (rootfs) used temporarily during system startup.
• The Security Enhanced Linux file system (selinuxfs) used for configuring the
selinux system. SELinux adds additional restrictions to access checks and
is beyond the scope of the TOE.
Note: This evaluation focuses on the use of the TOE as a server or a network
of servers. Therefore a graphical user interface has not been included as part of
the evaluation. In addition the evaluation assumes the operation of the network
of servers in a non-hostile environment.
1.6 Assumptions about the operating environment
The constraints concerning the allowed hardware and peripherals are made in
the Security Target (refer to [6], chapter 2.4.2).
Hardware platforms:
B-10
BSI-DSZ-CC-0427-2007 Certification Report
• Dell PowerEdge 1850 (EM64T) RHEL 4 Server Certified (described in [9])
• HP ProLiant DL380 G5 (EM64T) RHEL 4 Server Certified (described in
[10])
Peripherals:
• all terminals supported by the TOE (except hot pluggable devices
connected via USB or IEEE 1394 (Firewire) interfaces).
• printers compatible with PostScript level 1 or PCL 4 attached via parallel
port, USB, or Ethernet.
• all storage devices and backup devices supported by the TOE (hard disks,
CDROM drives, streamer drives, floppy disk drives) (except hot pluggable
devices connected via USB or IEEE 1394 (Firewire) interfaces)
• all Ethernet and Token-Ring network adapters supported by the TOE
Note: peripheral devices are part of the TOE environment.
Note: Excluding hot pluggable devices connected via USB does not exclude all
USB devices. USB printers, keyboards and mice may be attached provided they
are connected before booting the operating system.
The following constraints concerning the operating environment are made in the
Security Target. The constraints are based on the assumptions defined in [6],
chapter 3.4 and are repeated in the following table:
Assumption Addressed issue
A.LOCATE The processing resources of the TOE will be located
within controlled access facilities which will prevent
unauthorized physical access.
A.PROTECT The TOE hardware and software critical to security
policy enforcement will be protected from unauthorized
physical modification.
A.MANAGE 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.
A.NO_EVIL_ADMIN The system administrative personnel are not careless,
willfully negligent, or hostile, and will follow and abide
by the instructions provided by the administrator
documentation.
A.COOP Authorized users possess the necessary authorization
to access at least some of the information managed by
the TOE and are expected to act in a cooperating
manner in a benign environment.
A.UTRAIN Users are trained to use the security functionality
provided by the system appropriately.
A.UTRUST Users are trusted to accomplish some task or group of
tasks within a secure IT environment by exercising
complete control over their data.
B-11
Certification Report BSI-DSZ-CC-0427-2007
Assumption Addressed issue
A.NET_COMP All network components (such as bridges and routers)
are assumed to correctly pass data without
modification.
A.PEER Any other systems with which the TOE communicates
are assumed to be under the same management
control and operate under the same security policy
constraints.
There are no security requirements which address the
need to trust external systems or the communications
links to such systems.
A.CONNECT All connections to peripheral devices and all network
connections not using the secured protocols SSH v2 or
SSL v3 reside within the controlled access facilities.
Internal communication paths to access points such as
terminals or other systems are assumed to be
adequately protected.
Table 8: Assumptions defined in the Security Target
The following constraints are based on Security Objectives which have to be
met by the TOE environment. Theses objectives are defined in [6], chapter 4.2
and are repeated here:
Security Objective Addressed issue
OE.ADMIN Those responsible for the administration of the TOE are
competent and trustworthy individuals, capable of
managing the TOE and the security of the information it
contains.
OE.CREDEN Those responsible for the TOE must ensure that user
authentication data is stored securely and not disclosed
to unauthorized individuals. In particular:
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 purpose of the
system.
The media on which authentication data is stored must
not be physically removable from the system by other
than administrative users.
Users must not disclose their passwords to other
individuals.
OE.INSTALL Those responsible for the TOE must establish and
implement procedures to ensure that the hardware,
software and firmware components that comprise the
system are distributed, installed and configured in a
secure manner.
OE.PHYSICAL Those responsible for the TOE must ensure that those
parts of the TOE critical to security policy are protected
B-12
BSI-DSZ-CC-0427-2007 Certification Report
Security Objective Addressed issue
from physical attack which might compromise IT
security objectives.
OE.INFO_PROTECT Those responsible for the TOE must establish and
implement procedures to ensure that information is
protected in an appropriate manner. In particular:
DAC protections on security critical files (such as
configuration files and authentication databases) shall
always be set up correctly.
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
unless one of the secure protocols provided by the TOE
is used for the communication with another trusted
entity.
This requires that users are trained to perform those
tasks properly and trustworthy to not deliberately
misuse their access to information and pass it on to
somebody that does not have the right to access the
information.
OE.MAINTENANCE Administrative users of the TOE must ensure that any
diagnostics facilities provided by the product are
invoked at every scheduled preventative maintenance
period.
OE.RECOVER Those responsible for the TOE must ensure that
procedures and/or mechanisms are provided to assure
that, after system failure or other discontinuity, recovery
without a protection (i.e., security) compromise is
obtained.
OE.SOFTWARE_IN Those responsible for the TOE shall ensure that the
system shall be configured so that only an
administrative user can introduce new trusted software
into the system.
OE.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
terminals) are used.
OE.HW_SEP The underlying hardware must provide separation
mechanism that can be used by the TOE to protect the
TSF and TSF data from unauthorized access and
modification.
OE.PROTECT Those responsible for the TOE must ensure that
procedures and/or mechanisms exist to ensure that
data transferred between servers is secured from
disclosure, interruption or tampering (when using
communication links not protected by the use of the
SSL or SSH protocols. Note that interruption of
communication is not prevented by the use of those
B-13
Certification Report BSI-DSZ-CC-0427-2007
Security Objective Addressed issue
protocols and if protection against interruption of
communication is required, adequate protection in the
TOE environment has to be established for all
communication links).
Table 9: Security Objectives for the TOE environment
1.7 Disclaimers
The Certification Results only apply to the version of the product indicated in the
Certificate and on the condition that all the stipulations are kept as detailed in
this Certification Report. This certificate is not an endorsement of the IT product
by the Federal Office for Information Security (BSI) or any other organisation
that recognises or gives effect to this certificate, and no warranty of the IT
product by BSI or any other organisation that recognises or gives effect to this
certificate, is either expressed or implied.
2 Identification of the TOE
The Target of Evaluation (TOE) is called:
Oracle Enterprise Linux Version 4 Update 4
The following table outlines the TOE deliverables:
No Type Identifier Release Form of Delivery
1 SW Oracle Enterprise Linux Version 4
Update 4
CD ISO Images, Download
2 SW RPM software packages as
listed below.
na Download
3 DOC CAPP EAL4 Evaluated
Configuration Guide for
Oracle Enterprise Linux 4
U4 and U5
1.3 Download
Table 10: Deliverables of the TOE
In addition to the CD ISO images the following additional packages have to be
downloaded from Oracle through their internet representation. The user has to
ensure the integrity of the downloaded software before using the packages:
• kernel-2.6.9-55.0.0.0.2.EL.x86_64.rpm
• kernel-devel-2.6.9-55.0.0.0.2.EL.x86_64.rpm
• kernel-smp-2.6.9-55.0.0.0.2.EL.x86_64.rpm
• kernel-smp-devel-2.6.9-55.0.0.0.2.EL.x86_64.rpm
• audit-libs-1.0.14-1.EL4.i386.rpm
B-14
BSI-DSZ-CC-0427-2007 Certification Report
• audit-libs-devel-1.0.14-1.EL4.i386.rpm
• capp-eal4-config-oracle-1.0-1.EL4.noarch.rpm
Installing no 1 and 2 of the table above results in a system which has the
software packages as listed in [6], chapter 2.3 in place.
To install and configure the TOE such that it matches the configuration
described in the Security Target the user has to follow the guidance provided in
[11]. The Evaluated Configuration Guide provides all information on how to
install and configure the TOE in accordance with the Security Target.
3 Security Policy
The Security Policy which is implemented by the TOE is defined in [6], chapter
6.1.5. This policy is refined by an extensive Security Policy Model document
(confidential) that has been subject to analysis under the assurance component
ADV_SPM.1 as required by EAL4. An overview as given in the ST is provided
here:
The TOE is a single Oracle Enterprise Linux system running on one machine.
Several of those systems may be interconnected via a local area network and
exchange information using the network services. But one should keep in mind
that the following statements hold:
• Each host computer in the networked system runs the Oracle Enterprise
Linux kernel.
• Identification and authentication (I&A) is performed locally by each host
computer. Each user is required to Login with a valid password and user
identifier combination at the local system and also at any remote computer
where the user can enter commands to a shell program (using ssh). User ID
and password for one human user may be different on different hosts. User
ID and password on one host system are not known to other host systems
on the network and therefore a user ID is relevant only for the host where it
is defined.
• Discretionary access control (DAC) is performed locally by each of the host
computers and is based on user identity and group membership on this
host. Each process has an identity (the user on whose behalf it is operating)
and belongs to one or more groups. All named objects have an owning
user, an owning group and a DAC attribute, which is a set of permission
bits. In addition, file system objects optionally have extended permissions
also known as an Access Control List (ACL). The ACL mechanism is a
significant enhancement beyond traditional UNIX systems, and permits
control of access based on lists of users and/or groups to whom specific
permissions may be individually granted or denied.
• Object reuse is performed locally, without respect to other hosts.
• Interrupt handling is performed locally, without respect to other hosts.
B-15
Certification Report BSI-DSZ-CC-0427-2007
• Privilege is based on the root identity. All privileged processes (setuid root
programs and programs run under the root identity) start as processes with
all privileges enabled. Unprivileged processes, which include setgid trusted
processes, start and end with no privileges enabled.
4 Assumptions and Clarification of Scope
4.1 Usage assumptions
Based on the personnel assumptions the following usage conditions exist. Refer
to [6], chapter 3.4.2 for more details:
• A.MANAGE
• A.NO_EVIL_ADMIN
• A.COOP
• A.UTRAIN
• A.UTRUST
Please note that only the names have been listed here. The details can be
found either in the ST or in chapter 1.6 of this report.
4.2 Environmental assumptions
The following assumptions about physical and connectivity aspects defined by
the Security Target have to be met (refer to Security Target [6], chapter 3.4.1
and 3.4.3):
• A.LOCATE
• A.PROTECT
• A.NET_COMP
• A.PEER
• A.CONNECT
Please consider also the requirements for the evaluated configuration specified
in chapter 8 of this report.
B-16
BSI-DSZ-CC-0427-2007 Certification Report
4.3 Clarification of scope
The threats listed below have to be averted in order to support the TOE security
capabilities but are not addressed by the TOE itself. They have to be addressed
by the operating environment of the TOE (for detailed information about the
threats and how the environment may cover them refer to the Security Target
[6]).
Environmental Threat Addressed issue
TE.HWMF An attacker with legitimate physical access to the
hardware of the TOE (examples are maintenance
personnel or legitimate users) or environmental
conditions may cause a hardware malfunction with the
effect that a user (normal or administrative) is losing
stored data due to this hardware malfunction. An
attacker may cause such a hardware malfunction either
by having physical access to the hardware the TOE is
running on or by executing software that capable of
causing hardware malfunction. Note that such a
hardware malfunction may be caused accidentally
without malicious intent by persons having physical
access to the TOE.
TE.COR_FILE An attacker (possibly, but not necessarily, an
unauthorized user of the TOE) or environmental
conditions like a hardware malfunction may intentionally
or accidentally modify or corrupt security enforcing or
relevant files of the TOE without an administrative user
being able to detect this. An attacker may corrupt such
files either by having physical access to the hardware
the TOE is running on, by booting other software than
the TOE in its evaluated configuration or by modifying
or corrupting files on backup media. Note that such a
corruption may be caused accidentally without
malicious intent by persons having legitimate access to
media where such data is stored.
TE.HW_SEP An attacker (possibly, but not necessarily, an
unauthorized user of the TOE) with legitimate physical
access to the hardware the TOE is running on or
environmental conditions may cause the underlying
hardware functions of the hardware the TOE is running
on to not provide sufficient capabilities to support the
self-protection of the TSF from unauthorized programs.
Note that this also covers persons with legitimate
access to the TOE hardware causing such a problem
accidentally without malicious intent.
Table 11: Threats to be averted by the TOE environment
B-17
Certification Report BSI-DSZ-CC-0427-2007
5 Architectural Information
General overview:
Oracle Enterprise Linux Version 4 Update 4 (OEL) is a general-purpose, multi-
user, multi-tasking Linux based operating system. The version provides a
platform for a variety of applications in the governmental and commercial
environment.
The evaluation covers a potentially distributed, but closed network (which may
contain a router connecting to other networks) of the hardware systems listed in
section 2.4.2 in the ST running the evaluated version of OEL. The hardware
platforms selected for the evaluation consist of machines which are available
when the evaluation was completed and are intended to remain available for a
substantial period of time afterwards.
The TOE Security Functions (TSF) consist of functions of OEL that run in kernel
mode plus some trusted processes. These are the functions that enforce the
security policy as defined in this Security Target. Tools and commands
executed in user mode that are used by an administrative user need also to be
trusted to manage the system in a secure way. But as with other operating
system evaluations they are not considered to be part of this TSF.
Also the hardware and the BootProm firmware are not considered to be part of
the TOE.
The TOE includes installation from CD-ROM and from a local hard disk
partition. Installation from the local hard disk partition is required when the TOE
is installed on a real or virtual system without a CD-ROM.
The TOE includes standard networking applications, such as ftp and ssh. It also
includes the stunnel client and server program that allows to set up a trusted
channel using the SSL v3 protocol. xinetd can be used to protect network
applications which might otherwise have security exposures.
System administration tools include the standard commands. A graphical user
interface for system administration or any other operation is not included in the
evaluated configuration.
The TOE environment also includes applications that are not evaluated, but are
used as unprivileged tools to access public system services. For example a
HTTP server using a port above 1024 (e. g. on port 8080) may be used as a
normal application running without root privileges on top of the TOE. If this
server should be accessed via a SSL protected connection only, stunnel as part
of the TSF can be used to provide this trusted channel.
Major structural units of the TOE
The TOE is structured in much the same way as many other operating systems,
especially Unix-type operating systems. It consists of a kernel, which runs in the
privileged state of the processor and provides services to applications (which
those can be used by calling kernel services via the system call interface).
B-18
BSI-DSZ-CC-0427-2007 Certification Report
Direct access to the hardware is restricted to the kernel, so whenever an
application wants to access hardware like disk drives, network interfaces or
other peripheral devices, it has to call kernel services. The kernel then checks if
the application has the required access rights and privileges and either
performs the service or rejects the request.
The kernel is also responsible to separate the different user processes. This is
done by the management of the virtual and real memory of the TOE which
ensures that processes executing with different attributes can not directly
access memory areas of other processes but have to do so using the inter-
process communication mechanism provided by the kernel as part of its system
call interface.
The TSF of the TOE also include a set of trusted processes, which when
initiated by a user with a system call operate with extended privileges. The
programs that represent those trusted processes on the file system are
protected by the file system discretionary access control security function
enforced by the kernel.
In addition the execution of the TOE is controlled by a set of configuration files,
which are also called the TSF database. Also those configuration files are
protected by the file system discretionary access control security function
enforced by the kernel.
Normal users – after they have been successfully authenticated by a defined
trusted process – can start untrusted applications where the kernel enforces the
security policy of the TOE when those applications request services from the
kernel via the system call interface.
The kernel itself is structured into a number of subsystems which are explained
in detail in the high level design of the TOE. Those are:
File and I/O Subsystem
Implements all file system object related functions. Functions include those that
allow a process to create, maintain, interact and delete file-system objects, such
as regular files, directories, symbolic links, hard links, device special files,
named pipes, and sockets.
Process Control Subsystem
Implements functions related to process and thread management. Functions
include those that allow the creation, scheduling, execution, and deletion of
process and thread subjects.
Memory Management Subsystem
Implements functions related to the management of a system’s memory
resources. Functions include those that create and manage virtual memory,
including management of page tables and paging algorithms.
B-19
Certification Report BSI-DSZ-CC-0427-2007
Networking Subsystem
This subsystem implements UNIX and internet domain sockets as well as
algorithms for scheduling network packets.
IPC Subsystem
Implements functions related to inter-process communication mechanisms.
Functions include those that facilitate controlled sharing of information between
processes, allowing them to share data and synchronize their execution in order
to interact with a common resource.
Audit Subsystem
Implements the kernel functions required to intercept system calls and audit
them in accordance with the auditing policy defined by the system administrator.
Kernel Modules Subsystem
This subsystem implements an infrastructure to support loadable modules.
Functions include those that load and unload kernel modules.
Device Driver Subsystem
Implements support for various hardware devices through common, device
independent interface.
The trusted processes include the following subsystems:
Identification and Authentication
This subsystem includes all the processes that require to identify and
authenticate users. All those processes share a common set of functions
(pluggable authentication modules (PAM)) that ensure the same policy to be
enforced with respect to identification and authentication of users. Successful
as well as unsuccessful authentication attempts can be audited.
Network Applications
This subsystem includes the trusted processes implementing networking
functions. The TOE supports FTP and SSH v2 as well as setting up a secure
channel to another trusted system via the stunnel client and server processes
using the SSL v3 protocol. The secure configuration as defined in the Security
Target restricts the cipher suites that can be used for secure communication.
System Management
This subsystem includes the trusted commands a system administrator can use
to manage users and groups, set the time and date and check the integrity of
the underlying abstract machine.
Batch Processing
This subsystem includes the cron and at trusted processes that allow to execute
user programs at predefined time schedules. They ensure that the users are
restricted to the same security policy restrictions that also apply when they start
programs interactively.
B-20
BSI-DSZ-CC-0427-2007 Certification Report
User Level Audit
This subsystem includes all the trusted processes and commands outside of the
kernel required to collect, store and process audit records.
In addition to those functions the TOE includes a secure system initialization
function which brings the TOE into a secure state after it is powered on or after
a reset. This function ensures that user interaction with the TOE can only occur
after the TOE is securely initialized and in a secure state.
Security Functions
The security functions of the TOE defined in the Security Target are:
Identification and Authentication
The TOE provides identification and authentication using pluggable
authentication modules (PAM) based upon user passwords. The quality of the
passwords used can be enforced through configuration options controlled by
the TOE. Other authentication methods (e. g. Kerberos authentication, token
based authentication) that are supported by the TOE as pluggable
authentication modules are not part of the evaluated configuration. Functions
ensure a basic password strength and limit the use of the su command and
restrict root login to specific terminals are also included.
Audit
The TOE provides the capability to audit a large number of events including
individual system calls as well as events generated by trusted processes. Audit
data is collected in regular files in ASCII format. The TOE provides a program
for the purpose of searching the audit records.
The system administrator can define a rule base to restrict auditing to the
events he is interested in. This includes the ability to restrict auditing to specific
events, specific users, specific objects or a combination of all of this.
Discretionary Access Control
Discretionary Access Control (DAC) restricts access to file system objects
based on Access Control Lists (ACLs) that include the standard UNIX
permissions for user, group and others. Access control mechanisms also
protect IPC objects from unauthorized access.
The TOE includes the ext3 file system, which supports POSIX ACLs. This
allows defining access rights to files within this type of file system down to the
granularity of a single user.
Object Reuse
File system objects as well as memory and IPC objects will be cleared before
they can be reused by a process belonging to a different user.
B-21
Certification Report BSI-DSZ-CC-0427-2007
Security Management
The management of the security critical parameters of the TOE is performed by
administrative users. A set of commands that require root privileges is used for
system management. Security parameters are stored in specific files that are
protected by the access control mechanisms of the TOE against unauthorized
access by users that are not administrative users.
Secure Communication
The TOE supports the definition of trusted channels using either the SSH v2 or
the SSL v3 protocol. In the case of SSH the TOE includes the SSH server and
client functions. Password based authentication is supported.
To use the SSL v3 protocol the TOE provides the stunnel client and server
functions.
Only a restricted number of cipher suites are supported for those protocols in
the evaluated configuration. They are listed in the Security Target.
TSF Protection
While in operation, the kernel software and data are protected by the hardware
memory protection mechanisms. The memory and process management
components of the kernel ensure a user process cannot access kernel storage
or storage belonging to other processes.
Non-kernel TSF software and data are protected by DAC and process isolation
mechanisms. In the evaluated configuration, the reserved user ID root owns the
directories and files that define the TSF configuration. In general, files and
directories containing internal TSF data (e.g., configuration files, batch job
queues) are also protected from reading by DAC permissions.
The TOE and the hardware and firmware components are required to be
physically protected from unauthorized access. The system kernel mediates all
access to the hardware mechanisms themselves, other than program visible
CPU instruction functions.
6 Documentation
The following documentation is provided with the product by the developer to
the customer:
CAPP EAL4 Evaluated Configuration Guide for Oracle Enterprise
Linux 4 U4 and U5, Version 1.3, 2007-06-20, Orcale Corporation,
[11]
Document [11] contains a full description of the installation and configuration
process to get the evaluated configuration of the TOE. Please note that it is the
central document providing administrator guidance to the secure administration
of the TOE. This guide has been developed to address all security issues
related to the TOE and its security functions as described in the Security Target.
Advice given in this guide takes precedence over any other guidance document.
B-22
BSI-DSZ-CC-0427-2007 Certification Report
7 IT Product Testing
Test configuration
The Security Target defines the following hardware platforms for the TOE:
• Dell PowerEdge 1850 (EM64T) RHEL 4 Server Certified
• HP ProLiant DL380 G5 (EM64T) RHEL 4 Server Certified
The sponsor has performed his tests on the above listed hardware platforms.
The software was installed and configured as defined in the Evaluated
Configuration Guide [11].
Depth/Coverage of Testing
The developer has done substantial functional testing of all externally visible
interfaces (TSFI). Internal interfaces of the High-level design have been
covered by direct and indirect testing. The evaluators repeated the developer
tests (because of the highly automated testing approach of the developer) and
conducted additional independent tests and penetrations tests.
Summary of Developer Testing Effort
Test configuration:
The sponsor/developer has performed the tests on the following hardware
platform:
• Dell PowerEdge 1850 (Intel Xeon EM64T based system)
• HP ProLiant DL380 G5 (Intel Xeon EM64T based system)
The software was installed and configured as in the Guidance Documents (refer
to chapter 6). Additional software was installed on the system to perform the
tests. A rationale was given why this additional software was within the
boundary defined by the Security Target and did not constitute a violation of the
evaluated configuration.
Testing approach:
The sponsor/developer used several test suites and manual tests to test the
TOE. One of the test suites used was the LTP test suite. It is an adapted
version of tests from the Linux Test Project. The tests have a common
framework in which individual test cases adhere to a common structure for
setup execution and cleanup of tests. Each test case may contain several tests
of the same function, stressing different parts (for example, base functionality,
behaviour with illegal parameters and reaction to missing privileges). Each test
within a test case reports PASS respectively OK or FAIL and the test case
summary in batch mode reports PASS if all the tests within the test case
passed, otherwise FAIL. Tests can be executed either manually by running the
individual test case files or run in batch mode by running an overall script.
Testing results:
All actual test results were consistent with the expected test results.
B-23
Certification Report BSI-DSZ-CC-0427-2007
Summary of Evaluator Testing Effort
Test configuration:
The evaluator was provided with a test system that was pre-installed with the
evaluated configuration. To verify that the system's configuration is consistent
with the evaluated configuration set forth in the Evaluated Configuration Guide
[11], the evaluator verified that the resulting system configuration of each
installation and configuration step outlined in the guide is present.
The evaluator used the following test system:
• Dell PowerEdge 1850
The system was located in the Oracle facility in Redwood Shores, CA. This
system was used by the sponsor to perform the developer testing of the TOE.
Testing approach:
Since the developer tests are highly automated the evaluation facility decided to
re-run all automated developer tests but on a 64-bit platform only. In addition
evaluator tests were defined and executed by the evaluation facility.
Testing results:
All actual test results were consistent with the expected test results.
Evaluator penetration testing:
The evaluators devised a set of penetration tests based on
• common sources for vulnerabilities of the Linux Operating System,
• findings of their evaluation work examination.
The penetration testing showed no vulnerabilities which are exploitable in the
intended operating environment with the attack potential assumed for the
chosen EAL.
8 Evaluated Configuration
According to the Security Target the evaluated configuration of the TOE is
defined as follows (refer also to the Security Target [6]):
The TOE Oracle Enterprise Linux Version 4 Update 4 is delivered via electronic
download. The TOE contains a set of CD ISO images and the following
additional packages:
• kernel-2.6.9-55.0.0.0.2.EL.x86_64.rpm
• kernel-devel-2.6.9-55.0.0.0.2.EL.x86_64.rpm
• kernel-smp-2.6.9-55.0.0.0.2.EL.x86_64.rpm
• kernel-smp-devel-2.6.9-55.0.0.0.2.EL.x86_64.rpm
• audit-libs-1.0.14-1.EL4.i386.rpm
• audit-libs-devel-1.0.14-1.EL4.i386.rpm
B-24
BSI-DSZ-CC-0427-2007 Certification Report
• capp-eal4-config-oracle-1.0-1.EL4.noarch.rpm
The integrity and authenticity of the downloaded software has to be verified
before the installation process.
For a precise listing of all the packages please that make up the evaluated
configuration of the TOE please refer to [6], chapter 2.3.
The configuration requirements for the TOE are defined in chapter 2.4 and
subsequent chapters of the Security Target [6] and are also summarised in the
chapters 1.5 and 1.6 of this report.
9 Results of the Evaluation
The Evaluation Technical Report (ETR), [7] was provided by the ITSEF
according to the Common Criteria [1], the Methodology [2], the requirements of
the Scheme [3] and all interpretations and guidelines of the Scheme (AIS) [4] as
relevant for the TOE.
The verdicts for the CC, Part 3 assurance components (according to EAL4
augmented and the class ASE for the Security Target evaluation) are
summarised in the following table.
Assurance classes and components Verdict
Security Target evaluation CC Class ASE PASS
TOE description ASE_DES.1 PASS
Security environment ASE_ENV.1 PASS
ST introduction ASE_INT.1 PASS
Security objectives ASE_OBJ.1 PASS
PP claims ASE_PPC.1 PASS
IT security requirements ASE_REQ.1 PASS
Explicitly stated IT security requirements ASE_SRE.1 PASS
TOE summary specification ASE_TSS.1 PASS
Configuration management CC Class ACM PASS
Partial CM automation ACM_AUT.1 PASS
Generation support and acceptance procedures ACM_CAP.4 PASS
Problem tracking CM coverage ACM_SCP.2 PASS
Delivery and operation CC Class ADO PASS
Detection of modification ADO_DEL.2 PASS
Installation, generation, and start-up procedures ADO_IGS.1 PASS
Development CC Class ADV PASS
Fully defined external interfaces ADV_FSP.2 PASS
Security enforcing high-level design ADV_HLD.2 PASS
B-25
Certification Report BSI-DSZ-CC-0427-2007
Assurance classes and components Verdict
Subset of the implementation of the TSF ADV_IMP.1 PASS
Descriptive low-level design ADV_LLD.1 PASS
Informal correspondence demonstration ADV_RCR.1 PASS
Informal TOE security policy model ADV_SPM.1 PASS
Guidance documents CC Class AGD PASS
Administrator guidance AGD_ADM.1 PASS
User guidance AGD_USR.1 PASS
Life cycle support CC Class ALC PASS
Identification of security measures ALC_DVS.1 PASS
Systematic flaw remediation ALC_FLR.3 PASS
Developer defined life-cycle model ALC_LCD.1 PASS
Well-defined development tools ALC_TAT.1 PASS
Tests CC Class ATE PASS
Analysis of coverage ATE_COV.2 PASS
Testing: high-level design ATE_DPT.1 PASS
Functional testing ATE_FUN.1 PASS
Independent testing – sample ATE_IND.2 PASS
Vulnerability assessment CC Class AVA PASS
Validation of analysis AVA_MSU.2 PASS
Strength of TOE security function evaluation AVA_SOF.1 PASS
Independent vulnerability analysis AVA_VLA.2 PASS
Table 12: Verdicts for the assurance components
The evaluation has shown that:
• the TOE is conform to the PP Controlled Access Protection Profile, Issue
1.d, 8 October 1999, [8]
• Security Functional Requirements specified for the TOE are Common
Criteria Part 2 extended
• the assurance of the TOE is Common Criteria Part 3 conformant, EAL4
augmented by ALC_FLR.3 – Systematic flaw remediation.
• The following TOE Security Function fulfils the claimed Strength of
Function: User authentication based on passwords (IA).
The rating of the strength of functions does not include the cryptoalgorithms
suitable for encryption and decryption (see BSIG Section 4, Para. 3, Clause 2).
This holds for the Security Function SC (Secure Communication).
B-26
BSI-DSZ-CC-0427-2007 Certification Report
The results of the evaluation are only applicable to the operating system Oracle
Enterprise Linux Version 4 Update 4 as outlined in chapter 2 of this report.
The validity can be extended to new versions and releases of the product,
provided the sponsor applies for re-certification or assurance continuity of the
modified product, in accordance with the procedural requirements, and the
evaluation of the modified product does not reveal any security deficiencies.
10 Comments/Recommendations
The operational document [11] contains necessary information about the usage
of the TOE and all security hints therein have to be considered.
11 Annexes
None.
12 Security Target
For the purpose of publishing, the security target [6] of the target of evaluation
(TOE) is provided within a separate document.
13 Definitions
13.1 Acronyms
BSI Bundesamt für Sicherheit in der Informationstechnik / Federal
Office for Information Security, Bonn, Germany
CC Common Criteria for IT Security Evaluation
EAL Evaluation Assurance Level
IT Information Technology
PP Protection Profile
SF Security Function
SFP Security Function Policy
SOF Strength of Function
ST Security Target
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Functions
TSP TOE Security Policy
B-27
Certification Report BSI-DSZ-CC-0427-2007
13.2 Glossary
Augmentation - The addition of one or more assurance component(s) from CC
Part 3 to an EAL or assurance package.
Extension - The addition to an ST or PP of functional requirements not
contained in part 2 and/or assurance requirements not contained in part 3 of the
CC.
Formal - Expressed in a restricted syntax language with defined semantics
based on well-established mathematical concepts.
Informal - Expressed in natural language.
Object - An entity within the TSC that contains or receives information and
upon which subjects perform operations.
Protection Profile - An implementation-independent set of security require-
ments for a category of TOEs that meet specific consumer needs.
Security Function - A part or parts of the TOE that have to be relied upon for
enforcing a closely related subset of the rules from the TSP.
Security Target - A set of security requirements and specifications to be used
as the basis for evaluation of an identified TOE.
Semiformal - Expressed in a restricted syntax language with defined
semantics.
Strength of Function - A qualification of a TOE security function expressing
the minimum efforts assumed necessary to defeat its expected security
behaviour by directly attacking its underlying security mechanisms.
SOF-basic - A level of the TOE strength of function where analysis shows that
the function provides adequate protection against casual breach of TOE
security by attackers possessing a low attack potential.
SOF-medium - A level of the TOE strength of function where analysis shows
that the function provides adequate protection against straightforward or
intentional breach of TOE security by attackers possessing a moderate attack
potential.
SOF-high - A level of the TOE strength of function where analysis shows that
the function provides adequate protection against deliberately planned or
organised breach of TOE security by attackers possessing a high attack
potential.
Subject - An entity within the TSC that causes operations to be performed.
Target of Evaluation - An IT product or system and its associated
administrator and user guidance documentation that is the subject of an
evaluation.
B-28
BSI-DSZ-CC-0427-2007 Certification Report
TOE Security Functions - A set consisting of all hardware, software, and
firmware of the TOE that must be relied upon for the correct enforcement of the
TSP.
TOE Security Policy - A set of rules that regulate how assets are managed,
protected and distributed within a TOE.
TSF Scope of Control - The set of interactions that can occur with or within a
TOE and are subject to the rules of the TSP.
14 Bibliography
[1] Common Criteria for Information Technology Security Evaluation, version
2.3, August 2005
[2] Common Methodology for Information Technology Security Evaluation
(CEM), Evaluation Methodology, version 2.3, August 2005
[3] BSI certification: Procedural Description (BSI 7125)
[4] Application Notes and Interpretations of the Scheme (AIS) as relevant for
the TOE.
[5] German IT Security Certificates (BSI 7148, BSI 7149), periodically
updated list published also on the BSI Web-site
[6] Security Target BSI-DSZ-0427-2007, Version 1.6, 2007-07-12, "Oracle
Enterprise Linux Version 4 Update 4 Security Target for CAPP
Compliance", Oracle Corporation UK Limited
[7] Evaluation Technical Report BSI-DSZ-CC-0427-2007, Version 2, 2007-
07-12, atsec information security GmbH (confidential document)
[8] Controlled Access Protection Profile, Issue 1.d, 8 October 1999
[9] Dell PowerEdge 1850 spec sheet, http://www.dell.com/downloads/-
global/products/pedge/en/1850_specs.pdf
[10] QuickSpecs HP ProLiant DL380 G5 Storage Server,
http://h18000.www1.hp.com/products/quickspecs/12559_na/-
12559_na.pdf
[11] CAPP EAL4 Evaluated Configuration Guide for Oracle Enterprise Linux 4
U4 and U5, Version 1.3, 2007-06-20, Orcale Corporation
B-29
Certification Report BSI-DSZ-CC-0427-2007
B-30
This page is intentionally left blank.
BSI-DSZ-CC-0427-2007 Certification Report
C Excerpts from the Criteria
CC Part1:
Conformance results (chapter 7.4)
„The conformance result indicates the source of the collection of requirements
that is met by a TOE or PP that passes its evaluation. This conformance result
is presented with respect to CC Part 2 (functional requirements), CC Part 3
(assurance requirements) and, if applicable, to a pre-defined set of
requirements (e.g., EAL, Protection Profile).
The conformance result consists of one of the following:
a) CC Part 2 conformant - A PP or TOE is CC Part 2 conformant if the
functional requirements are based only upon functional components in
CC Part 2.
b) CC Part 2 extended - A PP or TOE is CC Part 2 extended if the
functional requirements include functional components not in CC Part 2.
plus one of the following:
a) CC Part 3 conformant - A PP or TOE is CC Part 3 conformant if the
assurance requirements are based only upon assurance components in
CC Part 3.
b) CC Part 3 extended - A PP or TOE is CC Part 3 extended if the
assurance requirements include assurance requirements not in CC Part
3.
Additionally, the conformance result may include a statement made with respect
to sets of defined requirements, in which case it consists of one of the following:
a) Package name Conformant - A PP or TOE is conformant to a pre-
defined named functional and/or assurance package (e.g. EAL) if the
requirements (functions or assurance) include all components in the
packages listed as part of the conformance result.
b) Package name Augmented - A PP or TOE is an augmentation of a pre-
defined named functional and/or assurance package (e.g. EAL) if the
requirements (functions or assurance) are a proper superset of all
components in the packages listed as part of the conformance result.
Finally, the conformance result may also include a statement made with respect
to Protection Profiles, in which case it includes the following:
a) PP Conformant - A TOE meets specific PP(s), which are listed as part of
the conformance result.“
C-1
Certification Report BSI-DSZ-CC-0427-2007
CC Part 3:
Assurance categorisation (chapter 7.5)
“The assurance classes, families, and the abbreviation for each family are
shown in Table 1.
Assurance Class Assurance Family
CM automation (ACM_AUT)
ACM: Configuration management CM capabilities (ACM_CAP)
CM scope (ACM_SCP)
ADO: Delivery and operation Delivery (ADO_DEL)
Installation, generation and start-up (ADO_IGS)
Functional specification (ADV_FSP)
High-level design (ADV_HLD)
Implementation representation (ADV_IMP)
ADV: Development TSF internals (ADV_INT)
Low-level design (ADV_LLD)
Representation correspondence (ADV_RCR)
Security policy modeling (ADV_SPM)
AGD: Guidance documents Administrator guidance (AGD_ADM)
User guidance (AGD_USR)
Development security (ALC_DVS)
ALC: Life cycle support Flaw remediation (ALC_FLR)
Life cycle definition (ALC_LCD)
Tools and techniques (ALC_TAT)
Coverage (ATE_COV)
ATE: Tests Depth (ATE_DPT)
Functional tests (ATE_FUN)
Independent testing (ATE_IND)
Covert channel analysis (AVA_CCA)
AVA: Vulnerability assessment Misuse (AVA_MSU)
Strength of TOE security functions (AVA_SOF)
Vulnerability analysis (AVA_VLA)
Table 1: Assurance family breakdown and mapping”
C-2
BSI-DSZ-CC-0427-2007 Certification Report
Evaluation assurance levels (chapter 11)
“The Evaluation Assurance Levels (EALs) provide an increasing scale that
balances the level of assurance obtained with the cost and feasibility of
acquiring that degree of assurance. The CC approach identifies the separate
concepts of assurance in a TOE at the end of the evaluation, and of
maintenance of that assurance during the operational use of the TOE.
It is important to note that not all families and components from CC Part 3 are
included in the EALs. This is not to say that these do not provide meaningful
and desirable assurances. Instead, it is expected that these families and
components will be considered for augmentation of an EAL in those PPs and
STs for which they provide utility.”
Evaluation assurance level (EAL) overview (chapter 11.1)
“Table 6 represents a summary of the EALs. The columns represent a
hierarchically ordered set of EALs, while the rows represent assurance families.
Each number in the resulting matrix identifies a specific assurance component
where applicable.
As outlined in the next section, seven hierarchically ordered evaluation
assurance levels are defined in the CC for the rating of a TOE's assurance.
They are hierarchically ordered inasmuch as each EAL represents more
assurance than all lower EALs. The increase in assurance from EAL to EAL is
accomplished by substitution of a hierarchically higher assurance component
from the same assurance family (i.e. increasing rigour, scope, and/or depth)
and from the addition of assurance components from other assurance families
(i.e. adding new requirements).
These EALs consist of an appropriate combination of assurance components as
described in chapter 7 of this Part 3. More precisely, each EAL includes no
more than one component of each assurance family and all assurance
dependencies of every component are addressed.
While the EALs are defined in the CC, it is possible to represent other
combinations of assurance. Specifically, the notion of “augmentation” allows the
addition of assurance components (from assurance families not already
included in the EAL) or the substitution of assurance components (with another
hierarchically higher assurance component in the same assurance family) to an
EAL. Of the assurance constructs defined in the CC, only EALs may be
augmented. The notion of an “EAL minus a constituent assurance component”
is not recognised by the standard as a valid claim. Augmentation carries with it
the obligation on the part of the claimant to justify the utility and added value of
the added assurance component to the EAL. An EAL may also be extended
with explicitly stated assurance requirements.
C-3
Certification Report BSI-DSZ-CC-0427-2007
Assurance Class Assurance
Family
Assurance Components by
Evaluation Assurance Level
EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7
Configuration
management
ACM_AUT 1 1 2 2
ACM_CAP 1 2 3 4 4 5 5
ACM_SCP 1 2 3 3 3
Delivery and
operation
ADO_DEL 1 1 2 2 2 3
ADO_IGS 1 1 1 1 1 1 1
Development ADV_FSP 1 1 1 2 3 3 4
ADV_HLD 1 2 2 3 4 5
ADV_IMP 1 2 3 3
ADV_INT 1 2 3
ADV_LLD 1 1 2 2
ADV_RCR 1 1 1 1 2 2 3
ADV_SPM 1 3 3 3
Guidance
documents
AGD_ADM 1 1 1 1 1 1 1
AGD_USR 1 1 1 1 1 1 1
Life cycle
support
ALC_DVS 1 1 1 2 2
ALC_FLR
ALC_LCD 1 2 2 3
ALC_TAT 1 2 3 3
Tests ATE_COV 1 2 2 2 3 3
ATE_DPT 1 1 2 2 3
ATE_FUN 1 1 1 1 2 2
ATE_IND 1 2 2 2 2 2 3
Vulnerability
assessment
AVA_CCA 1 2 2
AVA_MSU 1 2 2 3 3
AVA_SOF 1 1 1 1 1 1
AVA_VLA 1 1 2 3 4 4
Table 6: Evaluation assurance level summary”
C-4
BSI-DSZ-CC-0427-2007 Certification Report
Evaluation assurance level 1 (EAL1) - functionally tested (chapter 11.3)
“Objectives
EAL1 is applicable where some confidence in correct operation is required, but
the threats to security are not viewed as serious. It will be of value where
independent assurance is required to support the contention that due care has
been exercised with respect to the protection of personal or similar information.
EAL1 provides an evaluation of the TOE as made available to the customer,
including independent testing against a specification, and an examination of the
guidance documentation provided. It is intended that an EAL1 evaluation could
be successfully conducted without assistance from the developer of the TOE,
and for minimal outlay.
An evaluation at this level should provide evidence that the TOE functions in a
manner consistent with its documentation, and that it provides useful protection
against identified threats.”
Evaluation assurance level 2 (EAL2) - structurally tested (chapter 11.4)
“Objectives
EAL2 requires the co-operation of the developer in terms of the delivery of
design information and test results, but should not demand more effort on the
part of the developer than is consistent with good commercial practice. As such
it should not require a substantially increased investment of cost or time.
EAL2 is therefore applicable in those circumstances where developers or users
require a low to moderate level of independently assured security in the
absence of ready availability of the complete development record. Such a
situation may arise when securing legacy systems, or where access to the
developer may be limited.”
Evaluation assurance level 3 (EAL3) - methodically tested and checked
(chapter 11.5)
“Objectives
EAL3 permits a conscientious developer to gain maximum assurance from
positive security engineering at the design stage without substantial alteration of
existing sound development practices.
EAL3 is applicable in those circumstances where developers or users require a
moderate level of independently assured security, and require a thorough
investigation of the TOE and its development without substantial re-
engineering.”
C-5
Certification Report BSI-DSZ-CC-0427-2007
Evaluation assurance level 4 (EAL4) - methodically designed, tested, and
reviewed (chapter 11.6)
“Objectives
EAL4 permits a developer to gain maximum assurance from positive security
engineering based on good commercial development practices which, though
rigorous, do not require substantial specialist knowledge, skills, and other
resources. EAL4 is the highest level at which it is likely to be economically
feasible to retrofit to an existing product line.
EAL4 is therefore applicable in those circumstances where developers or users
require a moderate to high level of independently assured security in
conventional commodity TOEs and are prepared to incur additional security-
specific engineering costs.”
Evaluation assurance level 5 (EAL5) - semiformally designed and tested
(chapter 11.7)
“Objectives
EAL5 permits a developer to gain maximum assurance from security
engineering based upon rigorous commercial development practices supported
by moderate application of specialist security engineering techniques. Such a
TOE will probably be designed and developed with the intent of achieving EAL5
assurance. It is likely that the additional costs attributable to the EAL5
requirements, relative to rigorous development without the application of
specialised techniques, will not be large.
EAL5 is therefore applicable in those circumstances where developers or users
require a high level of independently assured security in a planned development
and require a rigorous development approach without incurring unreasonable
costs attributable to specialist security engineering techniques.”
Evaluation assurance level 6 (EAL6) - semiformally verified design and
tested (chapter 11.8)
“Objectives
EAL6 permits developers to gain high assurance from application of security
engineering techniques to a rigorous development environment in order to
produce a premium TOE for protecting high value assets against significant
risks.
EAL6 is therefore applicable to the development of security TOEs for
application in high risk situations where the value of the protected assets
justifies the additional costs.”
C-6
BSI-DSZ-CC-0427-2007 Certification Report
Evaluation assurance level 7 (EAL7) - formally verified design and tested
(chapter 11.9)
“Objectives
EAL7 is applicable to the development of security TOEs for application in
extremely high risk situations and/or where the high value of the assets justifies
the higher costs. Practical application of EAL7 is currently limited to TOEs with
tightly focused security functionality that is amenable to extensive formal
analysis.“
C-7
Certification Report BSI-DSZ-CC-0427-2007
C-8
Strength of TOE security functions (AVA_SOF) (chapter 19.3)
“Objectives
Even if a TOE security function cannot be bypassed, deactivated, or corrupted,
it may still be possible to defeat it because there is a vulnerability in the concept
of its underlying security mechanisms. For those functions a qualification of their
security behaviour can be made using the results of a quantitative or statistical
analysis of the security behaviour of these mechanisms and the effort required
to overcome them. The qualification is made in the form of a strength of TOE
security function claim.”
Vulnerability analysis (AVA_VLA) (chapter 19.4)
"Objectives
Vulnerability analysis is an assessment to determine whether vulnerabilities
identified, during the evaluation of the construction and anticipated operation of
the TOE or by other methods (e.g. by flaw hypotheses), could allow users to
violate the TSP.
Vulnerability analysis deals with the threats that a user will be able to discover
flaws that will allow unauthorised access to resources (e.g. data), allow the
ability to interfere with or alter the TSF, or interfere with the authorised
capabilities of other users.”
"Application notes
A vulnerability analysis is performed by the developer in order to ascertain the
presence of security vulnerabilities, and should consider at least the contents of
all the TOE deliverables including the ST for the targeted evaluation assurance
level. The developer is required to document the disposition of identified
vulnerabilities to allow the evaluator to make use of that information if it is found
useful as a support for the evaluator's independent vulnerability analysis.”
“Independent vulnerability analysis goes beyond the vulnerabilities identified by
the developer. The main intent of the evaluator analysis is to determine that the
TOE is resistant to penetration attacks performed by an attacker possessing a
low (for AVA_VLA.2 Independent vulnerability analysis), moderate (for
AVA_VLA.3 Moderately resistant) or high (for AVA_VLA.4 Highly resistant)
attack potential.”