Oracle Common Criteria Security Target i
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
Oracle8i Security Target
Release 3 (8.1.7)
April 2001
Security Evaluations
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
ii Oracle Common Criteria Security Target
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
Common Criteria Security Target for Oracle8iTM
Database Server
Release 3 (8.1.7)
April 2001
Authors: Simon Lofthouse, Daniel Elliott, Howard Smith
Contributors: Duncan Harris, Lydia Frew, Seve Pannifer, John Morrissey
Copyright © 2001, 2000, 1999 Oracle Corporation. All rights reserved.This documentation contains proprietary information of Oracle Corpora-
tion; it is protected by copyright law. Reverse engineering of the software is prohibited. If this documentation is delivered to a U.S. Government
Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable:
RESTRICTED RIGHTS LEGEND
Use, duplication or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013,
Rights in Technical Data and Computer Software (October 1988).
Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.
The information in this document is subject to change without notice. If you find any problems in the documentation, please report them to us
in writing. Oracle Corporation does not warrant that this document is error free.
Oracle, SQL*Loader, and SQL*Net are registered trademarks of Oracle Corporation.
Oracle8i, PL/SQL, and Trusted Oracle8 are trademarks of Oracle Corporation.
All other products or company names are used for identification purposes only, and may be trademarks of their respective owners.
Oracle Common Criteria Security Target iii
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
Contents
1 Introduction...........................................................................1
Identification and CC Conformance ....................................................1
TOE Overview .....................................................................................1
TOE Product Components ...................................................................2
Document Overview ............................................................................3
2 TOE Description ...................................................................5
Oracle8i Architecture ...........................................................................5
An Oracle8i Database...........................................................................7
Access Controls....................................................................................8
Quotas.................................................................................................11
Identification and Authentication.......................................................12
Auditing..............................................................................................13
Security Management.........................................................................14
Other Oracle8i Security Features .......................................................15
3 Security Environment ........................................................19
Threats................................................................................................19
Organisational Security Policies ........................................................19
Assumptions.......................................................................................19
4 Security Objectives ............................................................21
TOE Security Objectives....................................................................21
Environmental Security Objectives....................................................21
iv Oracle Common Criteria Security Target
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
5 IT Security Requirements..................................................23
TOE Security Functional Requirements ............................................23
TOE Security Assurance Requirements ............................................28
Security Requirements for the IT Environment.................................28
Minimum Strength of Function .........................................................28
6 TOE Summary Specification .............................................29
TOE Security Functionality ...............................................................29
Security Mechanisms and Techniques...............................................38
Assurance Measures ..........................................................................38
7 Protection Profile Claims ..................................................41
PP Reference......................................................................................41
PP Tailoring .......................................................................................41
PP Additions ......................................................................................41
8 Rationale .............................................................................43
Security Objectives Rationale............................................................43
Security Requirements Rationale.......................................................43
TOE Summary Specification Rationale.............................................44
PP Claims Rationale ..........................................................................48
A References .........................................................................49
B Glossary .............................................................................51
Acronyms...........................................................................................51
Terms .................................................................................................52
Oracle Common Criteria Security Target 1
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
C H A P T E R
1 Introduction
This document is the security target for the Common Criteria evaluation of the
Oracle8i Database Server, Release 3 (8.1.7).
Identification and CC Conformance
Title: Oracle8i Security Target
Target of Evaluation (TOE): Oracle8i Server Enterprise Edition, with the
Distributed Database Option and the Objects Option.
Release: 3 (8.1.7)
Operating System Platforms: Microsoft Windows NT 4.0, Sun Solaris 8.
CC Conformance: Database Management System Protection Profile (DBMS PP)
[DPP]. The authentication packages claimed for the Microsoft Windows NT 4.0
platform are OS Authentication and Database Authentication. The authentication
package claimed for the Sun Solaris 8 platform is Database Authentication.
This Security Target conforms to [CC, Part 2] and [CC, Part 3]. No new SFRs have
been introduced and no augmented assurance criteria have been specified.
Assurance: EAL4.
Keywords: Oracle8i, O-RDBMS, database, security target, EAL4
Version of the Common Criteria [CC] used to produce this document: 2.1
TOE Overview
Oracle8i is an object-relational database management system (O-RDBMS), providing
advanced security functionality for multi-user distributed database environments. The
security functionality in Oracle8i includes:
• user identification and authentication, with password management options;
• access controls on database objects;
2 Oracle Common Criteria Security Target
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
• granular privileges for the enforcement of least privilege;
• user-configurable roles for privilege management;
• extensive and flexible auditing options;
• secure access to remote Oracle databases, and
• stored procedures, triggers and security policies for user-defined access controls
and auditing.
Oracle8i supports both client/server and standalone architectures. In addition,
Oracle8i supports multi-tier architectures, however in this environment any tier
(middle-tier) that communicates directly with the server is actually an Oracle client
and any lower tiers are outside of the scope of this ST. In all architectures, the Oracle8i
Server acts as a data server, providing access to the information stored in a database.
Access requests are made via Oracle8i interface products that provide connectivity to
the database and submit Structured Query Language (SQL) statements to the Oracle8i
data server. The Oracle8i interface products may be used on the same computer as the
data server, or they may run on separate client machines and communicate with the
data server via network interfaces.
TOE Product Components
The Oracle8i Server Enterprise Edition includes the products identified in Table 1.
Access to the Oracle8i server is provided by the interface products identified in Table
2. Features of the TOE products that cannot be used in configurations that comply
with the DBMS PP and this Security Target are identified in Table 3.
Table 1: TOE Server Products
TOE Server Products
Oracle8i™ Server Enterprise Edition 8.1.7
Distributed Database Option 8.1.7
Objects Option 8.1.7
Net8™ 8.1.7
TCP/IP Adapter 8.1.7
Table 2: TOE Interface Products
TOE Interface Products
Oracle Server Manager 8.1.7
Oracle Call Interface 8.1.7
SQL*Plus 8.1.7
Oracle Common Criteria Security Target 3
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
Document Overview
Chapter 2 of this security target provides a high-level overview of the security features
of the Oracle8i data server. Chapter 3 identifies the assumptions, threats, and security
policies of the Oracle8i TOE environment. Chapter 4 describes the security objectives
for the TOE and for the environment needed to address the assumptions, threats, and
security policies identified in Chapter 3. Chapter 5 identifies the Security Functional
Requirements (SFRs), the Security Assurance Requirements (SARs) and the security
requirements for the Oracle8i TOE environment. Chapter 6 summarises each TOE
Security Function (TSF) provided by Oracle8i to meet the security requirements.
Chapter 7 describes how the Oracle8i TOE conforms to the requirements of the
DBMS Protection Profile and Chapter 8 provides the rationale for the security claims
made within this security target.
Appendix A contains a list of references and Appendix B provides a glossary of the
terms.
Net8™ 8.1.7
TCP/IP Adapter 8.1.7
Table 3: Excluded Product Features
Product Excluded Features
Oracle8i Server Multithreaded Server Option 8.1.7
Table 2: TOE Interface Products
TOE Interface Products
4 Oracle Common Criteria Security Target
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
This Page Intentionally Blank
Oracle Common Criteria Security Target 5
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
C H A P T E R
2 TOE Description
This section describes the Oracle8i product features that provide security mechanisms
and contribute to the security of a system configured with the Oracle8i TOE. The
security features of the product are explained primarily in part IV of Oracle8i
Administrator’
s Guide [SAD] and in part VII of Oracle8i Server Concepts [SCN]. In
general, these descriptions correspond to the specifications of IT security functions
provided in chapter 6 of this Security Target.
This chapter describes the major elements of the Oracle8i architecture, the types of
database objects supported by Oracle8i, the access control mechanisms used to protect
those objects, controls on user resource consumption, the accountability and auditing
mechanisms, and the security management features provided by Oracle8i. Additional
Oracle8i security features that are not addressed by the security functional
requirements of Chapter 3 are also briefly discussed.
Oracle8i Architecture
The Oracle8i architectural components are described in detail in [SCN].
Database A database consists of a set of files which contain, in addition to some control data,
the information which is said to be stored in the database. Each database is an
autonomous unit with its own data dictionary that defines the database objects it
contains (e.g. tables, views, etc.). In a distributed system there can be many databases:
each database can contain many database objects, but each database object is stored
within a single database.
Instance An instance consists of a set of Oracle background processes, which do the work of
the DBMS by executing Oracle8i software, and a shared memory area. An instance is
therefore an active entity, and a database is passive. In order for users to access the
database, the instance must be started and must mount and open the database for use.
A database is persistent: it has an indefinite lifetime from the time it is created, and the
database files and contents exist independently of whether the database is mounted to
an instance and whether the underlying platform is running. The lifetime of an
6 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
instance can be indefinite, from when it is started to when it is shut down, and is
dependent on whether the underlying platform is running.
Database Connections and
Sessions
Each database user employs Oracle8i interface products to establish a database
connection to an Oracle8i server process for a particular database instance. If the user
is defined as a valid user for the database and has the required privileges, then the
server will create a database session for the user. While connected, the user can make
requests to the Oracle8i server to read and write information in the database. The
server handles each request, performing the read and write accesses to database
objects and returning data and results to the user, in accordance with the user’
s
privileges to database objects and other constraints configured by a database
administrative user.
Distributed Databases In a distributed environment, a user may access database objects from multiple
databases. After establishing an initial database session on one instance, the user can
transparently establish database sessions on other (remote) database instances using
database links. A database link identifies a remote database and provides
authentication information. By qualifying references to database objects with the
name of a database link, a user can access remote database objects. However, each
Oracle8i database instance is autonomous with respect to security — a remote server
enforces security based on the privileges of the user as defined in that remote database.
Structured Query Lan-
guage (SQL)
The Oracle8i server supports the ANSI/ISO SQL standard [SQL92] at the entry level
of compliance and provides Oracle-specific SQL language extensions. All operations
performed by the Oracle8i server are executed in response to an SQL statement that
specifies a valid SQL command.
• Data Definition Language (DDL) statements are statements which create, alter,
drop, and rename database objects, grant and revoke privileges and roles, config-
ure audit options; add comments to the data dictionary; and obtain statistical
information about the database and its use;
• Data Manipulation Language (DML) statements are statements which manipulate
the data controlled by database objects in one of four ways: by querying the data
held in a database object; by row insertions; by row deletion; by column update.
They include the command to lock a database object.
• Transaction Control statements are statements which manage changes made by
DML statements and help to ensure the integrity of the database. They include
commits and rollbacks for individual transactions, and checkpoints for the data-
base;
• Session Control statements dynamically manage the properties of a user’
s data-
base session.
• System Control statements dynamically manage the processes and parameters of
an Oracle8i database instance.
Programming Language/SQL (PL/SQL) is a procedural language supported by
Oracle8i that provides program flow control statements as well as SQL statements
[PLS]. Program units written in PL/SQL can be stored in a database and executed
during the processing of a user’
s SQL command.
In addition Oracle provides support for SQLJ at both the client and server, so that
database applications written in Java may be executed at the client or at the server.
Oracle Common Criteria Security Target 7
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
Client side interfaces The Oracle Call Interface (OCI - described in [OCI8]) provides an application
programming interface (API) for developing database applications written in high
level languages such as C. In addition Oracle supports two SQLJ client side models;
a thick client model where Java programs can make calls to the database via Net*8,
and a thin client model where Java programs can call the database server directly
bypassing the Net*8 interface.
An Oracle8i Database
An Oracle8i database contains the data dictionary and two different types of database
objects:
• schema objects that belong to a specific user schema and contain user-defined
information [SCN part IV]; and
• non-schema objects to organise, monitor, and control the database [SCN part II,
SAD].
In an Oracle8i database there are two kinds of user:
• normal users (note that this includes SYS and SYSTEM. [SAD, 1-2]);
• Database Administrator Roles SYSOPER and SYSDBA, which allow users to per-
form administrative tasks such as database startup and shutdown, and ALTER
DATABASE commands [SAD, 1-8].
Note that connecting to a database via the CONNECT INTERNAL command is supported
for backward compatibility reasons only.
Data Dictionary At the centre of an Oracle8i database is the data dictionary - a set of internal Oracle
tables that contain all of the information the Oracle8i server needs to manage the
database. The data dictionary tables are owned by the user SYS and can only be
modified by highly privileged users. [SCN] advises that no Oracle user should ever
alter any object contained in the SYS schema and the security administrator should
keep strict control of this central account. A set of read-only views is provided to
display the contents of the internal tables in a meaningful way and also allow Oracle
users to query the data dictionary without the need to access it directly.
All of the information about database objects is stored in the data dictionary and
updated by the SQL DDL commands that create, alter, and drop database objects.
Other SQL commands also insert, update, and delete information in the data dictionary
in the course of their processing.
Schema Objects A schema is a collection of user-defined database objects that are owned by a single
database user. Oracle8i with the Objects and Distributed Database Options supports
the schema object types identified in [SQL, 2-63].
A special schema PUBLIC is provided by Oracle8i to contain objects that are to be
accessible to all users of the database. Typically, the kinds of objects that are created
in the PUBLIC schema are:
• Public database links that define access to remote databases;
• Public synonyms which point to objects which all users may need to access.
8 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
Non-Schema Objects [SQL, 2-64] lists object types can be created and manipulated with SQL, but are not
contained within a schema. These include tablespaces, roles, profiles and users.
The primary storage management database object is a tablespace — it is used to
organise the logical storage of data. A suitably privileged user manages tablespaces
to:
• create new tablespaces and allocate database files to the tablespace,
• add database files to existing tablespaces to increase storage capacity,
• assign default tablespaces to users for data storage, and
• take tablespaces on-line and off-line for backup and recovery operations.
Within the database files, Oracle8i allocates space for data in three hierarchical
physical units: data blocks, extents, and segments. When a user creates a schema
object to store data (e.g., a table), a segment is created and the space for the segment
is allocated in a specific tablespace.
Database Users Oracle8i contains two kinds of user: normal users and the special database
administrative roles (SYSDBA and SYSOPER). Throughout this document the
following terms are used to describe these users:
• Normal User/Database Subject: A user who is explicitly authorised to access the
database by virtue of being explicitly defined and identified to an instance of the
Oracle8i Database Server. The pre-defined users SYS and SYSTEM are normal
users;
• Specially Authorised User: A user who is authorised to access the database by
virtue of having platform specific DBA or OPER access rights, or is listed in the
Oracle8i password file as a DBA or OPER user.
• Database Administrative User/Administrative User: Any user (either a normal or
a specially authorised user) who is authorised to perform a particular administra-
tive task. This authorisation may be granted via a database privilege or via the
DBA/OPER roles.
Note that the word authorised is used (e.g. “an authorised administrative user”) to
indicate the specified user type has the specific authorisation (e.g. via a privilege) for
the operation under consideration.
Database security is managed by privileged users through the maintenance of users,
roles, and profiles.
• USERS identify distinct database user names and their authentication method.
• ROLES provide a grouping mechanism for a set of privileges.
• PROFILES provide a set of properties (e.g., resource limits, password manage-
ment options) that can be assigned to individual users.
These security topics are discussed in detail in subsequent sections of this chapter.
Access Controls
Oracle8i access controls can be used to selectively share database information with
other users. The access control mechanisms can be used to enforce need-to-know
Oracle Common Criteria Security Target 9
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
style confidentiality as well as control data disclosure, entry, modification, and
destruction. In addition to the access controls enforced by the Oracle8i server,
application-specific access controls can be implemented using views and triggers to
mediate a user’
s access to application data.
Oracle8i controls access to database objects based on the privileges enabled in the
database session. There are two types of Oracle8i privileges: object privileges and
system privileges. Both object and system privileges may be granted directly to
individual users, or granted indirectly by granting the privilege to an Oracle role and
then granting the role to the user. Privileges and roles may also be granted to PUBLIC,
authorizing all database users for the privilege. During a database session, the
privileges enabled in the session may be changed using several Oracle8i mechanisms
that affect the set of privileges held by the session.
System Privileges Oracle8i provides over 80 distinct system privileges to support the concept of least
privilege — each database user can be granted only those system privileges that are
needed to perform his or her job function. Often end-users would only need a minimal
set of system privileges to connect to the database. Some administrative users may be
granted more powerful system privileges to authorise them to manage administrative
objects, bypass particular server access controls, or perform specialised operations. A
user may grant a system privilege to additional database users only if he or she holds
that privilege with an administrative option (WITH ADMIN OPTION).
Object Privileges An object privilege is permission to access a schema object in a prescribed manner
(e.g., to INSERT rows into a table or EXECUTE a stored procedure). The owner of
the schema containing the object may grant object privileges to other database users
or roles. In addition, the owner may grant other users the right to grant those object
privileges to additional database users (WITH GRANT OPTION).
Because object privileges are granted to users at the discretion of other users, this type
of security is termed discretionary. Oracle8i ensures that users who attempt to gain
access to objects have been granted the necessary object privileges for the specific
operation, or have an overriding system privilege or role. The owner of an object
always has total access to that object.
Roles Oracle8i facilitates correct privilege administration by enabling privileges to be
grouped together into database roles. The benefits of Oracle database roles include:
• Reduced privilege administration,
• Dynamic privilege management,
• Least privilege,
• Privilege bracketing, and
• Consistency.
Reduced privilege administration Rather than explicitly granting the same set of privileges to several users, the
privileges for a group of related users can be granted to a role, and then only the role
needs to be granted to each member of the group. Roles permit numerous Oracle
privileges to be granted or revoked with a single SQL statement.
Dynamic privilege management If the privileges of a group of users must change, only the privileges of the role(s) need
to be modified instead of the privileges granted to every user. The security domains of
all users granted the group's role automatically reflect the changes made to the role.
10 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
Least privilege The roles granted to a user can be selectively enabled (available for use) or disabled
(not available for use). This helps a user to control use of those privileges which could
result in unintended disclosure, entry, modification, or destruction of data.
Privilege Bracketing Because the Oracle data dictionary records which roles have been granted to the
current user, database applications can be designed to query the dictionary and
automatically enable and disable selective roles when a user attempts to execute
applications.
System Security Policy To enable centralised implementation of privilege management in a system of which
Oracle may be only one component, Oracle also provides for linking database roles to
platform-specific group access controls. In this way, database roles can only be
enabled by users if they are a current member of the appropriate group in the
underlying platform. This helps to ensure a correct and consistent implementation of
a system-wide security policy.
DDL Restriction Privileges held via roles cannot be used with DDL statements that require access to
database objects. For example, to create a view, a user requires access to the tables
referenced by the view. The user must have directly granted privileges authorizing
the access to the underlying tables. Privileges held via a role are not applicable when
the server performs the object access checking on DDL statements.
Pre-defined Roles By default Oracle8i databases contain several pre-defined roles including.:
• CONNECT — containing the system privileges to connect and create basic
schema objects,
• RESOURCE — containing the system privileges necessary to create PL/SQL
program units and triggers, and
• DBA — containing all system privileges WITH ADMIN OPTION.
These roles are provided for backward compatibility [SAD, 24-6] and can be modified
or removed by suitably privileged users.
Session Privileges During the database session, the privileges held by the session can vary. When a
database session is initially established, it has all of the system and object privileges
directly granted to the user or to PUBLIC. In addition, the session has all of the
privileges granted to any default roles associated with the user. The set of privileges
can be changed by
• Enabling and disabling roles,
• Accessing a view,
• Executing a stored program unit, or
• Firing a trigger as the result of a DML statement.
Enabling Roles During a database session, a user can enable and disable any granted role.
Consequently, the privileges of the database subject can be modified to reflect
different requirements for access to database objects.
Views When a user creates a view, that user must have directly granted privileges that
authorise access to all of the tables (or views) referenced in the view’
s query. In
addition, if the user holds the necessary privileges WITH GRANT option or WITH ADMIN
option, then the user may grant access to the view to other database users, authorizing
them for indirect access to the tables in the view. In this way, views can be used to
Oracle Common Criteria Security Target 11
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
restrict access to information based on complex SQL queries that select only the
authorised data from the tables.
Stored Program Units In order to use a stored program unit (procedure, function, or package), a user must
have the privilege to EXECUTE the program unit. However, when the program unit
runs, the privileges for its execution may be set to the owner’
s directly granted
privileges (definers rights), or the invoker’
s privileges (invokers rights) depending on
options set when the program unit is created. This allows access privileges to be
encapsulated with the database operations being performed by the program unit. Any
user with EXECUTE privilege for the program unit is authorised to indirectly access any
database objects accessible to the program unit’
s owner.
Triggers The security context for the execution of triggers is similar to that of stored program
units. When a trigger fires as a result of a table access, the execution privileges for the
trigger are set to the trigger owner’
s directly granted privileges rather than the
privileges of the user who initiated the table update.
Fine-grained Access Con-
trol
Fine-grained access control allows an administrator to associate security policies with
tables or views. These policies are implemented by PL/SQL functions and are always
enforced on normal users no matter how the data is accessed.
Different policies can be applied for SELECT, INSERT, UPDATE and DELETE operations.
It is also possible for more than one policy to be applied to a table, including building
on top of base policies in packaged applications.
Application Context An application context allows an application to make security decisions based on
additional attributes attached to a users session information. An application context
provides a protected session persistent storage area for additional user attributes
defined by the application.
Quotas
Using Oracle8i profiles, an administrative user can set quotas on the amount of
processing resources a user can consume during a databases session. Limits can be
specified for the following:
• enabled roles per session (via an init.ora parameter)
• database sessions per user,
• CPU time per session,
• CPU time per SQL call,
• connect time per session,
• idle time per session,
• database reads per session,
• database reads per SQL command, and
• a composite limit (based on CPU time, connect time, and database reads).
Once a profile has been created, it can be assigned to one or more users, depending
on their need for processing resources. When a user exceeds the resource limit, the
Oracle8i server will abort the operation, and, in some cases, terminate the user’
s
12 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
session, or, in other cases, simply terminate current SQL statement or rollback the
current transaction.
An administrative user may also set quotas on the amount of storage space that can be
allocated for each user’
s schema objects in any specific tablespace.
Identification and Authentication
Oracle8i always identifies authorised users of an Oracle8i database prior to
establishing a database session for the user. Authentication can be performed directly
by the Oracle8i server using passwords managed by the server, or the server can rely
on the authentication done by the underlying OS platform.
For OS authentication, the database user connects to the Oracle8i server without
specifying a user name or password. The server obtains the user’
s identity from the
OS, and if the user is an authorised database user, a database session is created.
For Oracle authentication, a user must specify a user name and password in order to
connect. The password is compared to the password for the user stored in the data
dictionary and if they match, a database session is created. The user’
s password is
stored in the data dictionary in a one-way encrypted form, so before the comparison is
made, the password specified by the user is also one-way encrypted.
Password Management A user may change his or her password at any time. Oracle8i provides the facility for
suitably privileged users to create password complexity check functions that can
screen new passwords for certain criteria, e.g. :
• a minimum number of characters in length;
• not equal to the user name;
• includes a minimum number of alphabetic, numeric, or punctuation characters;
• does not match any word on an internal list of words;
• differs from the previous password by a certain number of characters.
A database administrative user can also set password lifetime, a failed logon count
leading to account lockout, expiration options, and password reuse requirements in an
Oracle8i profile. By assigning different profiles to different groups of users, the
password management parameters can vary among users.
By default the database does not enforce any password profile limits, however it is
critical that certain password controls are used in all profiles such that the TOE
achieves a high strength of function for the password mechanism (see the Minimum
Strength of Function section in chapter 5). Guidance covering the different password
controls, and instructions for modifying profiles to achieve SOF-high, is provided in
Oracle8i Evaluated Configuration Document [ECD].
Special Authentication Specially authorised users may connect to the database to perform functions such as
starting up or shutting down an Oracle8i instance. These users can be authorised by
either the use of a password file, or by having platform-specific access rights.
Platform-specific access rights are normally established by being a member of a
special operating system group. On a UNIX platform, the group defaults to the ‘
dba’
Oracle Common Criteria Security Target 13
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
group but can be changed. On an NT platform, the fixed group is ORA<SID>_OPER or
ORA<SID>_DBA.
When a specially authorised user wants to undertake special operations, he or she
connects to the database through a special keyword: INTERNAL, AS SYSDBA or AS
SYSOPER. When connected using the INTERNAL or AS SYSDBA keywords the database
session then runs as the user SYS. When connected using the AS SYSOPER keyword the
database session then runs as the user PUBLIC.
Auditing
Oracle8i ensures that relevant information about operations performed by users can be
recorded so that the consequences of those operations can later be linked to the user in
question, and the user held accountable for his or her actions. Oracle8i does this by
providing auditing options which are designed to be as granular and flexible as
possible to ensure that exactly what needs to be audited, as dictated by the application
or system security policy, is recorded, but nothing more. This helps to ensure that the
size of audit trails remain manageable and the important records easily accessible.
Oracle8i provides capabilities to permit auditing plans to be quickly enabled to
implement crisis responses. In addition to the standard Oracle8i auditing features
described here, application-specific audit trails can be implemented using triggers to
capture auditing details about the changes made to the information in the database.
Audit Categories An administrative user can request auditing of a number of actions in each of three
categories:
• By Statement
Auditing specific types of SQL statements including database connections and
disconnections. Statement auditing can be set to audit one, several, or all users.
• By Object
Auditing specific statements on specific database objects for all users.
• By Privilege
Auditing use of specific system privileges. Privilege auditing can be set to audit
one, several, or all users.
Audit Options Administrative users can further focus each auditing request by specifying auditing for
only successful, only unsuccessful, or both successful and unsuccessful attempts.
Such users can also specify, for most audit events, that audit records be created by
session or by access: by session results in only a single record for an audited action for
the duration of a database session; by access results in a record for every occurrence
of an audited action.
Oracle also permits administrative users to assign default object auditing options
which will automatically be used for any new schema objects which are created.
Audit Records Oracle8i auditing permits audit information to be written to a database audit trail or to
the audit trail of the underlying operating system. The Oracle8i audit records always
includes the following elements when they are meaningful for the audited event:
• User;
• Session Identifier;
14 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
• Terminal Identifier;
• Name of Object Accessed;
• Operation Performed;
• Completion Code of Operation;
• Date and Timestamp;
• System Privilege Used.
Audit Analysis If Oracle writes to the database audit trail, then the powerful SQL data manipulation
facilities of the DBMS can be used by administrative users to perform selective audit
analysis of relevant database operations, user actions, uses of privilege, and object
accesses in a secure manner. Oracle provides a number of pre-defined views on the
database audit trail to assist in such audit analysis.
If Oracle is configured to write to an operating system audit trail, then platform
services can be used to consolidate and analyse the database audit trail with audit trails
from other system components to provide a comprehensive auditing portrait for the
system. Alternatively, the audit data in the operating system or network services audit
trail could be loaded securely into an Oracle database for comprehensive audit
analysis using the SQL data manipulation facilities of the DBMS.
Auditing of SYS Although actions undertaken by the normal user SYS are auditable, no information
about actions performed by users connected as the special user SYS (through the
special keywords INTERNAL, AS SYSDBA and AS SYSOPER) are recorded in the Oracle8i
audit trail. However, this type of special connection, along with attempts to startup or
shutdown an instance are always recorded. These specific audit records are written to
the OS platform audit trail because they are OS events and because the database may
not be available to be written into.
Since the special database user SYS owns the database audit trail table, users connected
as SYS may read and write all rows in the audit trail table. Any normal user granted
appropriate object privileges on the database audit trail, or appropriate system
privileges, may also access the database audit trail to perform audit trail analysis and
clear out old audit records, but such accesses can be audited.
Security Management
Oracle8i provides a number of mechanisms to support the management of database
security. This section discusses the administrative system privileges, the importance
of the initialization file, the use of CONNECT INTERNAL, AS SYSOPER and AS SYSDBA,
and Oracle8i server dependencies on the administration of the underlying OS
platform.
Administrative Privileges Oracle8i contains over 80 distinct system privileges. Each system privilege allows a
user to perform a particular database operation or class of database operations. If a user
has no privileges then they cannot perform any operations, including connecting to the
database.
Normally, ordinary users would be given a minimal set of privileges allowing them to
connect to the database and access the necessary data. Other users may be given the
Oracle Common Criteria Security Target 15
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
ability to perform specific administrative functions by being granted specific system
privileges.
Oracle8i security management can be delegated, therefore, to any number of users.
Site-specific roles can be defined to delegate administrative responsibilities based on
organisational structures.
Initialization File When an Oracle8i instance is started, the parameters specified in an initialisation file
specify operational characteristics of Oracle8i server functionality, including security
functionality. It is critical that the security parameters specified in the initialization
file for the instance be set to the values which conform to the evaluated configuration.
The parameter values required by this security target are identified in Oracle8i
Evaluated Configuration Document [ECD].
SYSDBA and SYSOPER When a user is connected as INTERNAL, AS SYSOPER or AS SYSDBA, the user is
authorised to perform special database operations. Authorisation to connect as
INTERNAL, AS SYSDBA or AS SYSOPER is made via OS mechanisms (i.e., membership
in an OS-defined group) and requires that a user be authenticated by the OS, or by an
Oracle8i password.
A user connected AS SYSOPER is authorised to perform database startup, shutdown, and
backup operations. A user connected as INTERNAL or AS SYSDBA has the same
authorizations as SYSOPER with the additional capabilities to create databases and
perform the operations allowed by all system privileges WITH ADMIN option. Users
who connect as INTERNAL, AS SYSOPER and AS SYSDBA have access to all of the data
dictionary tables (which are owned by the user SYS).
OS Administration The security of the data managed by the Oracle8i data server is dependent not only on
the secure administration of Oracle8i, but also on the correct administration of the
underlying OS platform and any other nodes connected in a distributed environment.
The requirements on OS and network configuration for this security target are
identified in Oracle8i Evaluated Configuration Document [ECD]. Guidance for the
correct configuration of Oracle8i for a specific OS platform is contained in the
Oracle8i Installation and Configuration Guide [ICG] for that platform.
Other Oracle8i Security Features
In addition to the security features described above, Oracle8i provides features which
are related to security but do not directly address any of the functional requirements
identified in this Oracle8i Security Target. However, they provide significant security
capabilities to support robust and reliable database applications:
Data Integrity Oracle8i provides mechanisms to ensure that the consistency and integrity of data held
in a database can be maintained. These mechanisms are transactions, concurrency
controls, and integrity constraints. Transactions ensure that updates to the database
occur in well-defined steps that move the database from one consistent state to
another. Transactions and concurrency controls together ensure that multiple users
can have shared access to the database with consistent and predictable results: each
user sees a consistent state of the database and can make updates without interfering
with other users. Integrity constraints ensure that the values of individual data items
are of the defined type and within defined limits, and that defined relationships
between database tables are properly maintained.
16 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
Import/Export It is important to ensure that data can be moved out of one database and re-inserted
into the same or a different database while maintaining the data integrity and
confidentiality. Oracle enables secure exporting of information from a database into
an operating system file. Only appropriately privileged users may export information
to which they do not normally have read access. Similarly, Oracle enables secure
importing of information into a database from Oracle-generated operating system
export files. Only appropriately privileged users may import information into
database tables to which they do not normally have write access.
When a database object is exported, the list of users having object privileges to access
the object can also be exported and then imported into the new database with the
database object.
Backup and Recovery Backup of an Oracle8i database can be performed using platform-specific backup
programs, the Oracle8i import/export utilities, or the Oracle8i recovery manager. The
choice of mechanism depends upon the application needs, but all approaches can
provide secure, reliable backup and recovery of the database.
The Oracle8i transaction integrity mechanisms also provide the basis for secure
recovery following the failure of an Oracle8i instance or platform operating system.
Whenever an Oracle8i instance is started, any transactions that were not committed
prior to the failure are rolled back. This returns all of the information in the database,
including the data dictionary tables, to a consistent and secure state.
Secure Distributed Process-
ing
The basic distributed features included in the Oracle8i server make use of database
links to define a connection path to a remote Oracle database. When a connection is
made to a remote database, the information in the database link definition is used to
provide identification and authentication information to the remote Oracle server. The
remote server creates a database session for the user specified by the database link (if
the user is authorised for access to the remote database) and then makes its access
control decisions based on that identity and its privileges in the remote database.
By using database links to qualify schema object names, a user in a local database can
• select (e.g., join) data from tables in any number of remote Oracle databases,
• use DML statements to update tables in remote Oracle databases (Oracle8i auto-
matically implements a two-phase commit protocol), and
• execute stored program units in remote Oracle databases.
Access to the remote database is transparent; however careful administration and
control of the distributed environment is essential [SD1].
Oracle add-on products include the Advanced Networking Option and the Oracle
Security Server. The Advanced Networking Option provides encryption of the Oracle
network traffic between clients and servers and between two communicating servers
and adaptors for various external authentication services and certificate authorities.
The Oracle Security Server supports global authentication and global management of
Oracle roles.
Supplied Packages A number of standard packages are available to install in an Oracle8i database. These
provide supportive functionality that can be invoked by other users and applications.
They provide the following types of functions:
• Access to SQL features from PL/SQL programs, including dynamic SQL,
Oracle Common Criteria Security Target 17
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
• Alert mechanisms for asynchronous notification of database events,
• File access functions to read and write OS files,
• Job queues for scheduling repeating administrative procedures,
• Lock management functions for user-defined locks,
• Oracle pipes for communication among database sessions,
• Output operations for procedure debugging,
• Functions to manipulate LOBs,
• Queues for asynchronous message generation and delivery (Advanced Queuing),
• Administration of distributed transactions and snapshots, and
• HTTP callouts to access Web services.
External Authentication
Services
In addition to the standard Oracle8i database authentication and OS authentication
methods described above, Oracle8i can be configured to use an external third party
authentication service.
18 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
This Page Intentionally Blank
Oracle Common Criteria Security Target 19
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
C H A P T E R
3 Security Environment
Threats
As per [DPP, 3.2].
Organisational Security Policies
As per [DPP, 3.3];
Assumptions
As per [DPP, 3.4] with the following modifications and additions:
TOE Assumptions
A.TOE.CONFIG The TOE is installed, configured and managed in accordance
with [ECD], its evaluated configuration.
A.TOE.DBA In accordance with A.MANAGE [DPP, 3.4.2.2], trusted users are
required to use Oracle Server Manager for all privileged
connections to the TOE.
Underlying System Assumptions
A.MIDTIER To ensure accountability in multi-tier environments, any middle-
tier(s) will pass the original client ID through to the TOE.
20 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
This Page Intentionally Blank
Oracle Common Criteria Security Target 21
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
C H A P T E R
4 Security Objectives
TOE Security Objectives
As per [DPP, 4.1].
Environmental Security Objectives
As per [DPP, 4.2].
22 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
This Page Intentionally Blank
Oracle Common Criteria Security Target 23
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
C H A P T E R
5 IT Security Requirements
TOE Security Functional Requirements
Table 4 below lists each Security Functional Requirement (SFR) included in this Se-
curity Target and identifies which Common Criteria operations (assignment (A), se-
lection (S), refinement (R), and/or iteration (I)) have been applied to the requirement
relative to the DBMS Protection Profile [DPP].
The remainder of this section details the functional requirements as completed for this
Security Target. The text for completed operations is highlighted with ITALICISED
CAPITAL LETTERS within each requirement. Annex B provides definitions for vari-
ous terms used in the functional requirements.
Table 4: List of Security Functional Requirements
Component Name A S R I
FAU_GEN.1 Audit Data Generation X X
FAU_GEN.2 User Identity Association
FAU_SAR.1 Audit Review
FAU_SAR.3 Selectable Audit Review X
FAU_SEL.1 Selective Audit X
FAU_STG.1 Protected Audit Trail Storage
FAU_STG.4 Prevention of Audit Data Loss X X
FDP_ACC.1 Subset Access Control
FDP_ACF.1 Security Attribute Based Access Control X
FDP_RIP.2 Subset Residual Information Protection X
24 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
Security Audit FAU.GEN.1.1 The TSF shall be able to generate a database audit record of the
following auditable events:
a) Start-up and shutdown of the database audit functions;
b) All auditable events for the basic level of audit as identified in
Tables 4 & 7 of [DPP]; and
c) NO ADDITIONAL EVENTS.
FAU.GEN.1.2 The TSF shall record within each database audit record at least the
following information:
a) Date and time of the database event, type of database event,
database subject identity, and the outcome (success or failure) of
the event; and
b) For each database audit event type, based on the auditable event
definitions of the functional components included in the PP/ST,
OTHER RELEVANT INFORMATION AS IDENTIFIED IN
TABLES 4 & 7 OF [DPP].
FAU.GEN.2.1 The TSF shall be able to associate each auditable database event with
the identity of the database user that caused the event.
FAU.SAR.1.1 The TSF shall provide authorised database users with the capability
to read all database audit information from the database audit
records.
FIA_AFL.1 Basic Authentication Failure Handling X
FIA_ATD.1 User Attribute Definition X
FIA_SOS.1 Verification of Secrets X
FIA_UAU.1 Timing of Authentication X
FIA_UID.1 Timing of Identification X
FIA_USB.1 User-Subject Binding
FMT_MSA.1 Management of Security Attributes X
FMT_MSA.3 Static Attribute Initialisation X
FMT_MTD.1 Management of TSF Data
FMT_REV.1 Revocation X
FMT_SMR.1 Security Roles X
FPT_RVM.1 Non-Bypassability of the TSP
FPT_SEP.1 TSF Domain Separation
FRU_RSA.1 Maximum Quotas X
FTA_MCS.1 Basic Limitation on Multiple Concurrent Sessions X
FTA_TSE.1 TOE Session Establishment X
Component Name A S R I
Oracle Common Criteria Security Target 25
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
FAU.SAR.1.2 The TSF shall provide the database audit records in a manner suitable
for the database user to interpret the information.
FAU.SAR.3.1 The TSF shall provide the ability to perform searches and sorting of
database audit data based on THE VALUES OF AUDIT DATA
FIELDS.
FAU.SEL.1.1 The TSF shall be able to include or exclude auditable database events
from the set of audited database events based on the following
attributes:
a) event type;
b) database subject identity;
c) database object identity;
d) DATABASE SYSTEM PRIVILEGE.
FAU.STG.1.1 The TSF shall protect the stored database audit records from
unauthorised deletion.
FAU.STG.1.2 The TSF shall be able to prevent modifications to the database audit
records.
FAU.STG.4.1 The TSF shall prevent database audit events, except those taken by
the authorised database user with special rights, if the audit trail is
full.
User Data Protection FDP.ACC.1.1 The TSF shall enforce the database object access control SFP on:
a) database subjects;
b) database objects;
c) all permitted operations on database objects by database subjects
covered by the SFP.
FDP.ACF.1.1 The TSF shall enforce the database object access control SFP to
database objects based on:
a) the identity of the owner of the database object; and
b) the object access privileges to the database object held by the
database subject; and
c) the database administrative privileges of the database subject.
FDP.ACF.1.2 The TSF shall enforce the following rules to determine if an
operation among controlled database subjects and controlled
database objects is allowed:
a) if the user associated with the database subject is the owner of
the database object, then the requested access is allowed; or
b) if the database subject has the database object access privilege
for the requested access to the database object, then the requested
access is allowed; or
c) otherwise access is denied, unless access is explicitly authorised
in accordance with the rules specified in FDP.ACF.1.3.
FDP.ACF.1.3 The TSF shall explicitly authorise access of database subjects to
database objects based on the following additional rules:
a) if the database subject has a database administrative privilege to
override the database object access controls for the requested
access to the database object, then the requested access is
allowed;
26 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
b) IF THE SUBJECT IS CONNECTED AS INTERNAL OR AS
SYSBDA THEN THE REQUESTED ACCESS IS ALLOWED; OR
c) IF THE SUBJECT IS CONNECTED AS SYSOPER AND THE
REQUESTED ACTION IS ONE OF OPERATIONS
PERMITTED FOR THE SYSOPER USER SPECIFIED IN [SAG,
1-8], THEN THE REQUESTED ACCESS IS ALLOWED.
FDP.ACF.1.4 The TSF shall explicitly deny access of database subjects to database
objects based on the following additional rules: NONE.
FDP.RIP.2.1 The TSF shall ensure that any previous information content of a
database resource is made unavailable upon the allocation of a
resource to SCHEMA OBJECTS (INCLUDING NON-SCHEMA
OBJECTS, WHICH ARE STORED IN THE SYS SCHEMA).
Identification and Authen-
tication
FIA.AFL.1.1 The TSF shall detect when A NUMBER, CONFIGURED BY AN
AUTHORISED ADMINISTRATIVE USER, of unsuccessful database
authentication attempts occur related to THE USER’
S LAST
SUCCESSFUL DATABASE SESSION.
FIA.AFL.1.2 When the defined number of unsuccessful database authentication
attempts has been met or surpassed, the TSF shall LOCK THE
DATABASE USER’
S ACCOUNT.
FIA.ATD.1.1 The TSF shall maintain the following list of security attributes
belonging to individual database users:
a) database user identity;
b) database object access privileges;
c) database administrative privileges;
d) ORACLE ROLES.
FIA.SOS.1.1 The TSF shall provide a mechanism to verify that database secrets
(passwords) meet REUSE, LIFETIME, AND CONTENT METRICS
AS DEFINED BY AN AUTHORISED ADMINISTRATIVE USER.
FIA.UAU.1.1 The TSF shall allow THE FOLLOWING LIST OF ACTIONS on
behalf of the database user to be performed before the database user
is authenticated:
a) OBTAIN THE CURRENT ORACLE VERSION STRING AND
NUMBER;
b) ESTABLISH A DATABASE CONNECTION; AND
c) RECEIVE AN ERROR MESSAGE UPON ERROR.
FIA.UAU.1.2 The TSF shall require each database user to be successfully
authenticated before allowing any other TSF-mediated actions on
behalf of that database user.
FIA.UID.1.1 The TSF shall allow THE FOLLOWING LIST OF ACTIONS on
behalf of the database user before the database user is identified:
a) OBTAIN THE CURRENT ORACLE VERSION STRING AND
NUMBER;
b) ESTABLISH A DATABASE CONNECTION; AND
c) RECEIVE ERROR MESSAGES UPON ERROR.
FIA.UID.1.2 TheTSFshallrequireeachdatabaseusertobesuccessfullyidentified
before allowing any other TSF-mediated actions on behalf of that
database user.
Oracle Common Criteria Security Target 27
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
FIA.USB.1.1 The TSF shall associate the appropriate database user security
attributes with database subjects acting on behalf of that database
user.
Security Management FMT.MSA.1.1 The TSF shall enforce the database object access control SFP to
restrict the ability to modify the database object security attributes:
a) DATABASEOBJECTACCESSPRIVILEGES toTHE OBJECT’
S
OWNER AND OTHER DATABASE USERS AUTHORIZED BY
THE OWNER.
b) DATABASE SYSTEM PRIVILEGES to USERS WHO HAVE
BEEN GRANTED THAT PRIVILEGE WITH ADMIN OPTION
OR USERS WHO CONNECT INTERNAL OR AS SYSDBA.
c) DATABASE ROLES to DATABASE USERS AUTHORIZED TO
MODIFY ROLES.
FMT.MSA.3.1 The TSF shall enforce the database object access control SFP to
provide restrictive default values for database object security
attributes that are used to enforce the database object access control
SFP.
FMT.MSA.3.2 The TSF shall allow NO DATABASE USERS to specify alternative
initial values to override the default values when a database object
is created.
FMT.MTD.1.1 The TSF shall according to table 5 OF [DPP] restrict the ability to
perform operations on TSF data to database administrative users.
FMT.REV.1.1 The TSF shall restrict the ability to revoke security attributes
associated with the database users and database objects within the
TSC to:
a) authorised database administrators (for users and objects);
b) authorised database users (only for the database objects they own
or database objects for which they have been granted database
object access privileges allowing them to revoke security
attributes);
c) NO OTHER ROLES.
FMT.REV.1.2 The TSF shall enforce the FOLLOWING rules:
a) revocation of database object access privileges shall take effect
prior to all subsequent attempts to establish access to the database
object;
b) revocation of database administrative privileges shall take effect
prior to when the user begins the next database session;
c) NO ADDITIONAL REVOCATION RULES.
FMT.SMR.1.1 The TSF shall maintain the database roles:
a) database administrative user;
b) database user;
c) DATABASE ROLES DEFINED BY SUITABLY PRIVILEGED
DATABASE ADMINISTRATIVE USERS.
Note that due to a difference in terminology between the CC and the Oracle8i product
the two occurrences of the word “role”in FMT.SMR.1.1 have different meanings. The
first occurrence, which is part of the required CC wording, is a general term meaning
any kind of user that can be created within the TSF. The second occurrence, which is
part of a completed assignment in [DPP], is a specific term referring to Oracle8i da-
28 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
tabase roles that can be configured and granted to users of the Oracle8i product.
FMT.SMR.1.2 The TSF shall be able to associate database users with database roles.
Protection of the TOE
Security Functions
FPT.RVM.1.1 The TSF shall ensure that TSP enforcement functions are invoked
and succeed before each function within the TSC is allowed to
proceed.
FPT.SEP.1.1 The TSF shall maintain a security domain for its own execution that
protects it from interference and tampering by untrusted database
subjects.
FPT.SEP.1.2 The TSF shall enforce separation between the security domains of
database subjects in the TSC.
Resource Utilisation FRU.RSA.1.1 The TSF shall enforce maximum quotas of the following resources:
a) CPU_TIME;
b) ELAPSED TIME;
c) LOGICAL DATA BLOCKS READ; AND
d) DATABASE STORAGE ALLOCATED.
that an individual database user can use over a specified period of
time:
TOE Access FTA.MCS.1.1 The TSF shall restrict the maximum number of concurrent database
sessions that belong to the same database user.
FTA.MCS.1.2 The TSF shall enforce, by default, a limit of A NUMBER,
CONFIGURED BY AN AUTHORIZED ADMINISTRATIVE USER,
database sessions per database user.
FTA.TSE.1.1 The TSF shall be able to deny database session establishment based
on USER IDENTITY.
Note that the DBA and OPER users can always connect to the database.
TOE Security Assurance Requirements
The target assurance level is EAL4 as defined in Part 3 of the CC. No augmented as-
surance requirements are defined.
Security Requirements for the IT Environment
As per [DPP 5.5 & 5.6].
Minimum Strength of Function
The minimum strength of function for the TOE is High. This exceeds the requirements
in [DPP].
Oracle Common Criteria Security Target 29
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
C H A P T E R
6 TOE Summary
Specification
TOE Security Functionality
This section contains a high-level specification of each TOE Security Function (TSF)
that contributes to satisfaction of the Security Functional Requirements of chapter 5.
The specifications cover five major areas: identification and authentication, object
access controls, resource quotas, privileges and roles, and auditing. Table 5 below
shows that all the SFRs are satisfied by at least one TSF and that every TSF is used to
satisfy at least one SFR. Note that SFR FDP.ACF.1.4 is not satisfied by any TSF
because the SFR specifies null functionality.
30 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
Table 5: Mapping of TSFs to SFRs
Identification and Authen-
tication
F.IA.PRE Oracle shall only allow users to:
a) obtain the current Oracle version string and version
number;
b) establish a connection;
c) receive error messages upon error.
before identifying and authenticating the user.
F.IA.UID Each database user is uniquely identified.
FIA FDP FMT FPT
FRU
FTA FAU
AFL.1.1
AFL.1.2
ATD.1.1
SOS.1.1
UAU.1.1
UAU.1.2
UID.1.1
UID.1.2
USB.1.1
ACC.1.1
ACF.1.1
ACF.1.2
ACF.1.3
ACF.1.4
RIP.1.1
MSA.1.1
MSA.3.1
MSA.3.2
MTD.1.1
REV.1.1
REV.1.2
SMR.1.1
SMR.1.2
RVM.1.1
SEP.1.1
SEP.1.2
RSA.1.1
MCS.1.1
MCS.1.2
TSE.1.1
GEN.1.1
GEN.1.2
GEN.2.1
SAR.1.1
SAR.1.2
SAR.3.1
SEL.1.1
STG.1.1
STG.1.2
STG.4.1
F.IA.PRE Y Y Y Y
F.IA.UID Y Y
F.IA.DBA Y Y
F.IA.OSA Y Y
F.IA.CNF Y
F.IA.IDE Y Y Y Y
F.IA.CSA Y Y Y Y Y
F.IA.CSN Y Y Y Y
F.IA.PWD Y Y Y
F.IA.ATT Y Y Y
F.IA.USE Y
F.LIM.CNF Y Y Y Y
F.LIM.POL Y Y
F.LIM.NSESS Y Y Y
F.LIM.TIME Y
F.LIM.RSESS Y
F.LIM.RCALL Y
F.DAC.OBID Y Y Y
F.DAC.OBREF Y Y Y
F.DAC.SUA Y Y
F.DAC.OBA Y Y Y
F.DAC.POL Y Y Y Y Y Y
F.DAC.SEP Y Y
F.DAC.OR Y
F.APR.GOP Y Y Y
F.APR.ROP Y Y Y
F.APR.GRSP Y Y Y Y
F.APR.GRR Y Y Y Y Y
F.APR.DER Y
F.APR.EDR Y Y
F.PRI.SPRIV Y Y Y Y Y Y
F.PRI.XVP Y
F.PRI.PRX Y Y
F.AUD.SOM Y Y
F.AUD.SEV Y Y
F.AUD.ALW Y Y
F.AUD.CNF Y Y Y
F.AUD.ACC Y Y Y
F.AUD.DEL Y Y Y
F.AUD.INF Y Y
F.AUD.VIEW Y Y
F.AUD.FULL Y
Oracle Common Criteria Security Target 31
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
F.IA.DBA DBMS Identification and Authentication:
If a user is configured in the TOE as being identified by a
password then the TOE will:
a) identify the user by confirming that the user provides a
valid user identifier, and
b) authenticate the user by confirming that the user provides
a password corresponding to the stored password for that
user.
F.IA.OSA OS Identification and Authentication:
If a user is configured in the TOE as being identified externally
then the TOE will identify and authenticate the user by
confirming that the requesting subject’
s OS user identifier,
prefixed by the value of the OS_AUTHENT_PREFIX initialisation
parameter, matches a database user identifier.
Note that in F.IA.OSA the TOE is not performing any authentication, per se. Rather
the TOE is dependent on the OS to correctly authenticate the user.
F.IA.CSN The TOE will create a database session as a normal user only if
the CREATE SESSION privilege is held by the database user and the
TOE has identified and authenticated the user as a valid database
user (by either DBMS or OS identification and authentication).
F.IA.IDE For each interaction between a user and the TOE following the
successful creation of a database session, the TOE is able to
establish the identity of the user. A subject can only submit
requests to a Server and receive responses (information) from a
Server while the subject is establishing a connection or connected
to an instance during the course of a database session.
F.IA.CSA The TOE will create a database session as the DBA user (for AS
SYSDBA connections) or the OPER user (for AS SYSOPER
connections) only if either:
a) the requesting subject has the platform-specific access
rights for OSDBA and OSOPER, respectively, as defined in
[SAD, 1-7], or
b) the provided user identifier and password correspond to
users stored in the Oracle password file as being allowed
DBA or OPER connections, respectively.
F.IA.CNF The TOE will allow only a suitably authorised user to create a
database user.
F.IA.PWD The TOE provides the following configurable controls on user
passwords: [SQL, 7-338, CREATE PROFILE]
a) the number of failed login attempts before the user
account is locked,
b) the number of days the same password can be used before
expiring,
c) the number of days before which a password cannot be
reused,
32 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
d) the number of password changes required before the
current password can be reused,
e) the number of days a user account will be locked after the
specified number of consecutive failed logins,
f) the number of days of grace period after a password
expires before the user account is locked,
g) a password complexity check to screen passwords
selected by the user.
F.IA.ATT The data dictionary contains a unique set of security attributes
for each user including their username, password management
information, account status (i.e. locked or unlocked), privileges,
roles and resource limits that can be displayed and modified by
suitably privileged users using standard SQL commands.
F.IA.USE A database user is authorised to change the password associated
with that user within the following constraints:
a) If the user’
s profile includes a complexity check function,
then the new password is accepted only if it meets the
criteria of the complexity check.
b) If the user’
s profile specifies password reuse constraints
and the user attempts to reuse a password, the TOE rejects
the change if the reuse constraints are not met. [SQL, 7-
338].
Access Control
Database Resources F.LIM.CNF The TOE will allow only a suitably authorised user to:
a) alter the default Resource Profile for a database;
b) create and alter specific Resource Profiles and assign and
reassign them to each individual database users.
F.LIM.POL When a user attempts to use a database resource that is subject
to controls specified by Resource Profiles, the TOE will enforce
the limits specified by the resource profile (if any) explicitly
assigned to the user, otherwise it enforces the limits specified by
the default Resource Profile for the database.
F.LIM.NSESS The TOE prevents a user from creating more than the maximum
number of concurrent sessions specified for that user for an
instance of the TOE.
F.LIM.TIME If a user exceeds the specified CONNECT_TIME or IDLE_TIME
resource limits by the (OS specific) amount for a single session
then the TOE will terminate the session when the user attempts
an operation.
F.LIM.RSESS If a user attempts to perform an operation that exceeds the
specified resource limits for a single session then the TOE will:
a) terminate the operation;
b) force the termination of the session.
Oracle Common Criteria Security Target 33
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
F.LIM.RCALL If a user attempts to perform an operation that exceeds the
specified resource limits for a single SQL statement then the TOE
will terminate the operation.
Object Access Control F.DAC.OBID The TOE ensures that every object created in a database is
uniquely identified in that database. Specifically, each schema
object owned by a normal user is uniquely identified within the
user’
s schema1
.
F.DAC.OBREF The TOE correctly resolves every reference to a database object
that conforms to the Object naming rules specified in [SQL,
chapter 2], including references via database links2
.
F.DAC.SUA For normal users, the TOE enforces DAC on database objects
based on the following subject attributes:
a) the identity of the user associated with the database
session;
b) the system privileges and object privileges which are
effective for the database session.
F.DAC.OBA For normal users, the TOE enforces DAC on database objects
based on the following object attributes:
a) the identity of the owner of the object;
b) the object privileges which have been granted on the
object;
c) and any security policies in force for the object.
F.DAC.POL The TOE enforces the following rules to determine if an
operation among controlled subjects and controlled objects is
allowed:
a) If the user is the owner of the object then the requested
access is allowed.
b) If the database session has the necessary object privileges
effective for the object then the requested access is
allowed. The object privileges relevant to different types
of objects are specified in [SQL, 7-505, GRANT
object_privileges], and provide the ability to restrict a
user’
s access to an object to those operations which do not
modify the object.
c) If the database session has the necessary system privileges
effective then the requested access is allowed. The system
1. The owner of an object is the owner of the schema containing the object, not necessarily the user who
created the object. More precisely, unique identification is by object type as well as object name within a
schema.
2. A reference to a database link (e.g. CONNECT /@otherdb or SELECT * FROM TBL@otherdb) will
be correctly resolved to the referenced database. A database object can be uniquely identified in a distrib-
uted system, because it is uniquely identified in the database, and the database is unique in the system. The
threat is that failure to uniquely identify objects and user accounts could result in reading, creating, modi-
fying or destroying the wrong object (or copy of an object) if the user has the same access rights in each
database.
34 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
privileges relevant to different types of database-wide and
schema-specific operations are specified in [SQL, 7-493,
GRANT system_privileges_and_roles] and provide the
ability to restrict a user’
s use of operations to those
operations which do not modify objects.
d) If the user is the DBA user (the database session has the
privilege to override the access controls) then the
requested access is allowed.
e) If the user is the OPER user and the operation is one of
those specified in [SAD, Chapter 1 OSOPER and OSDBA],
for the OSOPER role then the requested access is allowed.
F.DAC.SEP The TOE does not allow interference between concurrent
database sessions.
F.DAC.OR Upon allocation of a resource to schema and non-schema objects,
any previous information is unavailable. In Oracle, there is no
way to access an object once it has been deleted, i.e. the resources
have been returned to the TOE. This is because any references to
it no longer exist and, even if they were recreated, they would
never be associated with the previous, non-existent object.
All objects have a unique ID. Even if a deleted object is recreated
using the same name, the object ID would be different.
Schema and non-schema objects are defined in [SQL, 2].
Privileges and Roles
Granting and Revoking Privileges
and Roles
F.APR.GOP A normal user (the grantor) can grant an object privilege to
another user, role or PUBLIC (the grantee) only if:
a) the grantor is the owner of the object; or
b) the grantor has been granted that object privilege with the
GRANT OPTION.
F.APR.ROP A normal user (the revoker) can revoke an object privilege from
another user, role or PUBLIC (the revokee), and any further
propagation of that object privilege started by the revokee, only
if the revoker is the original grantor of the object privilege.
F.APR.GRSP A user (the grantor) can grant a system privilege to another user,
role or PUBLIC (the grantee), and revoke a system privilege from
the grantee, only if:
a) the grantor (or revoker) is the DBA user; or
b) the database session of the grantor (or revoker) has the
GRANT ANY PRIVILEGE privilege effective; or
c) the grantor (or revoker) has been granted that system
privilege directly with the ADMIN OPTION.
F.APR.GRR A user (the grantor) can grant a role to another user, role or PUBLIC
(the grantee), and revoke a role from the grantee, only if:
a) the grantor is the DBA user; or
Oracle Common Criteria Security Target 35
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
b) the database session of the grantor (or revoker) has the
GRANT ANY ROLE privilege effective; or
c) the grantor (or revoker) has been granted that role with
the ADMIN OPTION
1
.
Enabling and Disabling Roles F.APR.DER A role can be granted to a user in one of the following ways:
a) As a non-default role, in which case the user must
explicitly enable the role during a database session in
order for any other roles within that role to be enabled and
any privileges within that role to become effective for that
user.
b) As a default role, in which case the role will be enabled
automatically for each database session created by that
user2.
F.APR.EDR During a database session the user can control which roles are
effective at any time during the course of the database session by
enabling and disabling the roles which have been granted to that
user (where the role may have been granted directly to the user
or granted indirectly to the user through other roles
3
), subject to
the following restrictions which apply to implicit remote
sessions:
a) The non-default roles granted to a user in a remote
database cannot be enabled while the user is connected to
the remote database.
b) The default roles granted to a user in a remote database
cannot be disabled while the user is connected to the
remote database.
Effective Privileges F.PRI.SPRIV A privilege will be effective in a user session only if:
a) the privilege was granted to the user directly and has not
been revoked from the user; or
b) the privilege was granted indirectly via the PUBLIC user
group and has not been revoked from PUBLIC; or
c) the privilege was granted to the user indirectly via a role,
and has not been revoked from that role and the role is
effective in the current session.
F.PRI.XVP A suitably authorised user can provide other users with access to
proxy mechanisms (namely Views and Program Units) which
will act on behalf of the owning user (by executing with the
1. This includes the case where the grantor is the user who created the role - see [SAD, 24-10, The Ad-
min option]: “When a user creates a role, the role is automatically granted to the creator with the ADMIN
OPTION.” and the warning on [SAD, 23-15, Setting Default Roles] which adds the fact that a role is auto-
matically granted to its creator as a default role.
2. A default role is enabled at session creation bypassing any authorisation required for that role.
3. When a role that has been granted other roles is enabled all the indirectly granted roles are implicitly
enabled.
36 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
directly granted privileges of the owning user) to allow other
users to have controlled access to specified aggregations of data.
F.PRI.PRX A suitably authorised user can provide other users with the ability
to establish a proxy connection for another user. The authorised
user can control which user roles are available to the proxy
session.
Audit and Accountability F.AUD.SOM When standard auditing is enabled (as DBMS or OS Auditing)
for an instance, the TOE will:
a) write an audit record for every occurrence of an auditable
event other than CONNECT and DISCONNECT; and
b) write an audit record for every pair of CONNECT/
DISCONNECT events.
F.AUD.SEV The TOE will allow a suitably authorised user to specify which
events for a database are auditable, as follows:
a) by use of DDL statements, for all users or for specified
users;
b) by use of DML statements;
i. for specified Object Privilege Objects;
ii. for all Object Privilege Objects subsequently
created, by default;
c) by use of system privileges, for all users or for specified
users;
d) for each event of type b) by session or by access, i.e. only
one audit record written for each auditable event that
occurs in the same session or one audit record written for
each auditable event. For events of type c) by session or
by access, unless a DDL statement when always by
access;
e) for each event of type a), b) and c) by outcome, i.e.
success, failure, or both.
F.AUD.ALW Irrespective of the TOE's audit configuration1
, the TOE will audit
every successful occurrence of the following events to the
operating system:
a) start-up;
b) shut-down;
c) connection through the keywords INTERNAL, AS SYSDBA
or AS SYSOPER.
1. For the Windows NT platform, OS auditable Oracle records are written to the NT event log. For the
Solaris platform, OS auditable Oracle records are written to standard text file audit logs in the OS.
Oracle Common Criteria Security Target 37
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
F.AUD.CNF The TOE will allow only a suitably authorised
1
user to set or alter
the audit configuration for a database.
F.AUD.ACC The TOE will allow suitably authorised users to select by criteria
audit information from the database audit trail, as follows:
a) any suitably privileged user can view all audit records;
b) the owner of an object can view the audit records relating
to that object.
F.AUD.DEL The TOE will allow only a suitably authorised
2
user to delete or
update audit records from the Database Audit Trail.
F.AUD.INF The TOE will record the following information into each
Database Audit Trail record, provided that the information is
meaningful to the particular audited event:
Date and time of event; username; instance ID for the Oracle
instance where the user is accessing the database; session
identifier; terminal identifier of the user’
s terminal; name of
object accessed; operation performed or attempted; outcome of
the operation; system privileges used.
In particular:
a) when a user attempts a connection to a database, whether
successful or not, at least the following information is
recorded when the TOE is configured to audit connection
attempts: date and time of event, username, instance ID
for the Oracle instance where the user is accessing the
database, session identifier, terminal identifier of the
user’
s terminal, outcome of the connection attempt;
b) when a user attempts to access any database object,
whether successful or not, at least the following
information is recorded when the TOE is configured to
audit such access attempts: date and time of event,
username, name of object accessed, operation performed
or attempted, outcome of the operation;
c) when a user attempts to create or drop any database object,
whether successful or not, at least the following
information is recorded when the TOE is configured to
audit such create or drop actions: date and time of event,
username, name of object to be created or dropped,
operation performed or attempted, outcome of the
operation;
d) when a user attempts to affect the security of the TOE, by,
for example, startup up and shutting down an instance of
1. By default (after installation), the TOE allows only the DBA user, SYS and SYSTEM (who are grant-
ed the DBA role during installation) to set and alter the audit configuration. It is possible for these users to
grant the relevant privileges to other users, but it is assumed that they will not do this in practice.
2. By default, the TOE allows only the DBA user, SYS and SYSTEM (who are granted the DBA role
during installation) to delete or update rows from SYS.AUD$. It is possible for these users to grant the rel-
evant privileges to other users, but it is assumed that they will not do this in practice.
38 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
the TOE, creating new, modifying existing or dropping
old user accounts, tablespaces, databases, rollback
segments, etc. as the TOE permits at least the following
information is recorded when the TOE is configured to
auditsuchactions:dateandtimeofevent,username,name
of object accessed, operation performed or attempted,
outcome of the operation.
F.AUD.VIEW Oracle provides both the SQL language and built-in views, based
on the underlying audit trail table SYS.AUD$, with the ability to
both view and search the audit data.
F.AUD.FULL With DBMS auditing, if the tablespace containing the audit trail
table becomes full, no further auditable actions can occur until
space is made available.
Security Mechanisms and Techniques
When authentication is performed by Oracle8i, a password is used for authentication.
The TOE employs a one-way encryption algorithm (modified Data Encryption
Standard (DES)) to encrypt passwords prior to storing them in the database. The TOE
password management functions (together called the PWD mechanism) provide a
Strength of Function level of SOF-high. This exceeds the DBMS PP Strength of
Function level of SOF-medium [DPP]. The TOE mechanisms, and the TSFs
comprising them, are shown in chapter 8.
Assurance Measures
The target assurance level is EAL4, which exceeds the assurance requirement of
EAL3 as stated in [DPP]. No specific assurance measures are claimed. The following
table identifies the Oracle8i documentation that supports each security assurance
requirement for EAL4.
Table 6: Oracle8i Assurance Measures
Component Name Documents
ACM_AUT.1 Partial CM Automation [CM]
ACM_CAP.4 Generation Support and
Acceptance Procs
[CM]
ACM_SCP.2 Problem Tracking CM
Coverage
[CM]
ADO_DEL.2 Detection of Modifica-
tion
[OSQM]
ADO_IGS.1 Installation, Genera-
tion, and Startup
[ICG]
ADV_FSP.2 Fully Defined External
Interfaces
[ADG] [ERR] [FS] [SQL]
Oracle Common Criteria Security Target 39
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
ADV_HLD.2 Security Enforcing
High-level Design
[AD] [OSD]
ADV_IMP.1 Subset of the TSF
Implementation
[SRC]
ADV_LLD.1 Descriptive Low-level
Design
[DD]
ADV_RCR.1 Informal Correspond-
ence Demonstration
[AD] [DD] [FS] [SRC]
ADV_SPM.1 Informal TOE Security
Policy Model
[SPM]
AGD_ADM.1 Administrator Guid-
ance
[ECD] [GA] [ICG] [SAD] [SRB]
AGD_USR.1 User Guidance [GA]
ALC_DVS.1 Identification of Secu-
rity Measures
[SODE]
ALC_LCD.1 Developer Defined Life
Cycle Model
[PRP]
ALC_TAT.1 Well Defined Develop-
ment Tools
[CM]
ATE_COV.2 Analysis of Coverage [TP]
ATE_DPT.1 Testing - High-level
Design
[TP]
ATE_FUN.1 Functional Testing [TP]
AVA_MSU.2 Validation of Analysis [GA]
AVA_SOF.1 Strength of TOE Secu-
rity Functions
[SOF]
AVA_VLA.2 Independent Vulnera-
bility Analysis
[VA]
Component Name Documents
40 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
This Page Intentionally Blank
Oracle Common Criteria Security Target 41
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
C H A P T E R
7 Protection Profile Claims
PP Reference
The TOE conforms to the Database Management System Protection Profile (DBMS
PP) [DPP].
PP Tailoring
Table 4 in chapter 5 identifies each SFR for this Security Target and the tailoring op-
erations performed relative to [DPP]. The tailoring is identified in ITALICISED CAP-
ITAL LETTERS within the text of each SFR in chapter 5. All of the tailoring
operations are in conformance with the assignments and selections in [DPP].
PP Additions
There are no additional threats, organisational security policies, or objectives included
in this security target.
A reference to [ECD] has been added to the assumption A.TOE.CONFIG. This does
not change the meaning of the assumption, rather it points to a TOE-specific document
where the evaluated configuration is defined.
An additional assumption, A.TOE.DBA, has been added which expands upon
A.MANAGE to ensure that all trusted users (i.e. database administrators) use the
Oracle Server Manager utility for their privileged connections. This additional as-
sumption does not change any meaning of [DPP], rather it adds a TOE-specific caveat.
There is an additional underlying system assumption A.MIDTIER, which is included
to ensure accountability in multi-tier environments. Although the O-RDBMS can au-
dit the actions of a proxy user, accountability relies upon the correct identity of the cli-
ent (given during the connection by the middle-tier). As explained in chapter 1 (TOE
Overview), this type of environment is a new addition to the scope of evaluation.
The assurance requirement specified in this security target is EAL4. This includes all
assurance requirements in [DPP] (which mandates EAL3).
42 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
This Page Intentionally Blank
Oracle Common Criteria Security Target 43
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
C H A P T E R
8 Rationale
Security Objectives Rationale
As per [DPP 6.1].
Security Requirements Rationale
Security Requirements Sat-
isfy the Security Objectives
There are no additional IT security objectives. Therefore, the ST complies fully with
the DBMS PP; see [DPP, 6.2, 6.3, and 6.4] for further information.
TOE Security Mechanisms The following security enforcing mechanisms are provided by the TOE :
Mechanism SFs Implemented
DBC - Database users and Schemas F.IA.PRE, F.IA.IDE, F.IA.UID,
F.IA.OSA, F.IA.CSA, F.IA.CSN,
F.IA.ATT, F.DAC.OBID,
F.DAC.OBREF, F.DAC.SEP,
F.DAC.OR
PWD - Database Passwords F.IA.DBA, F.IA.PWD, F.IA.USE,
F.IA.UID, F.IA.CSA, F.IA.ATT,
F.LIM.CNF, F.LIM.POL
PRIV - Privileges F.IA.ATT, F.DAC.SUA,
F.DAC.OBA, F.DAC.POL,
F.PRI.SPRIV, F.PRI.XVP,
F.PRI.PRX, F.APR.GOP,
F.APR.ROP, F.APR.GRSP,
F.APR.GRR, F.IA.CNF,
F.LIM.CNF, F.AUD.CNF,
F.AUD.ACC, F.AUD.DEL
Table 8-1: Security Enforcing Mechanisms
44 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
The PWD (Database Passwords) mechanism is probabilistic or permutational since it
relies on “secrets”(i.e. passwords) for its operation. This mechanism provides
Oracle8i database authentication using usernames and passwords, and configurable
password management controls which are enforced through user profile limits.
Strength of Function
Validity
The strength of function specified, SOF-high, exceeds the strength of function re-
quired by [DPP]. The PWD mechanism is the only TOE mechanism that is probabil-
istic or permutational, and has a strength of SOF-high. This strength of function is
intended to provide enough protection against straightforward or intentional attack
from threat agents having a high attack potential.
Assurance Measures Com-
pliant with Requirements
The target assurance level is EAL4, which exceeds the assurance requirement of
EAL3 as stated in [DPP]. No augmented assurance requirements are defined. See
[DPP] for further information.
TOE Summary Specification Rationale
This section demonstrates that the TOE Security Functions and Assurance Measures
are suitable to meet the TOE security requirements.
TOE Security Functions
Satisfy Requirements
Table 5 of chapter 6 identifies the Oracle8i TOE Security Functions that address each
of the SFRs in chapter 5.
Table 7 below demonstrates that for each SFR the TOE security functions are suitable
to meet the SFR, and the combination of TOE security functions work together so as
to satisfy the SFR:
ROL - Roles F.IA.ATT, F.APR.DER, F.APR.EDR
RES - Resource Profiles F.IA.ATT, F.LIM.POL, F.LIM.NS-
ESS, F.LIM.TIME, F.LIM.RSESS,
F.LIM.RCALL
AUD - Audit F.AUD.SOM, F.AUD.SEV,
F.AUD.ALW, F.AUD.INF,
F.AUD.ACC, F.AUD.VIEW,
F.AUD.FULL
Mechanism SFs Implemented
Table 8-1: Security Enforcing Mechanisms
Oracle Common Criteria Security Target 45
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
SFR
TOE
Security
Functions
Rationale
FIA.AFL.1.1 F.IA.PWD The number of allowed failed logon attempts can be con-
figured.
FIA.AFL.1.2 F.IA.PWD When the configured number of failed logon attempts is
reached the account is locked.
FIA.ATD.1.1 F.IA.ATT The data dictionary stores the required security attributes
FIA.SOS.1.1 F.IA.PWD
F.LIM.CNF
F.IA.USE
F.IA.PWD specifies the controls available on database
secrets (passwords). These controls are implemented via
profiles which are required by F.LIM.CNF. F.IA.USE
allows users to change their own passwords within the
limits configured by an administrator.
FIA.UAU.1.1 F.IA.PRE F.IA.PRE maps onto FIA.UAU.1.1 and FIA.UID.1.2
directly.
FIA.UAU.1.2 F.IA.PRE
F.IA.DBA
F.IA.OSA
F.IA.CSA
F.IA.CSN
F.IA.CSN and F.IA.CSA state the conditions for being
able to establish a database session and hence perform
TSF-mediated actions. These security functions depend
directly on F.IA.DBA and F.IA.OSA. F.IA.PRE is rele-
vant one of the actions allowed prior to session creation
is attempting to establish a session.
FIA.UID.1.1 F.IA.PRE F.IA.PRE satisfies FIA.UAU.1.1 and FIA.UID.1.1
directly.
FIA.UID.1.2 F.IA.PRE
F.IA.UID
F.IA.DBA
F.IA.OSA
F.IA.IDE
F.IA.CSA
F.IA.CSN
F.IA.CSN and F.IA.CSA state the conditions for being
able to establish a database session and hence perform
TSF-mediated actions. These security functions depend
directly on F.IA.DBA and F.IA.OSA. F.IA.PRE is rele-
vant one of the actions allowed prior to session creation
is attempting to establish a session. F.IA.PRE ensures
that the identity of the user is known for the duration of
the session, once created.
FIA.USB.1.1 F.IA.ATT
F.APR.EDR
F.PRI.SPRIV
F.PRI.XVP
F.PRI.PRX
F.IA.ATT provides the security attributes for each user.
The effective security attributes for a database session
are controlled by F.APR.EDR and F.PRI.SPRIV. In
addition, F.PRI.XVP defines security attributes associ-
ated with views and program units which act on behalf of
the owning user. F.PRI.PRX defines security attributes
associated with proxy user sessions.
FDP.ACC.1.1 F.DAC.OBID
F.DAC.OBREF
F.DAC.SUA
F.DAC.OBA
F.DAC.OBID and F.DAC.OBREF ensures that all
objects (which are subject to DAC) can be uniquely iden-
tified. F.DAC.SUA and F.DAC.OBA state that the DAC
policy extends to all subjects and objects.
FDP.ACF.1.1 F.DAC.OBID
F.DAC.OBREF
F.DAC.SUA
F.DAC.OBA
F.DAC.POL
F.PRI.SPRIV
F.DAC.OBID and F.DAC.OBREF ensures that all
objects (which are subject to DAC) can be uniquely iden-
tified. F.DAC.SUA includes the subject and their ena-
bled privileges (as specified in F.PRI.SPRIV) in the
DAC policy. F.DAC.OBA states that the object and any
associated object privileges are considered by the DAC
policy. F.DAC.POL is a statement of the DAC policy.
Table 7: TOE Security Function Suitability and Binding
46 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
FDP.ACF.1.2 F.IA.CNF
F.DAC.OBID
F.DAC.OBREF
F.DAC.POL
F.PRI.SPRIV
F.AUD.CNF
F.DAC.POL a) and b) specifies access to objects based
on ownership or object privileges. F.DAC.OBID and
F.DAC.OBREF are relevant as they define object owner-
ship which is the basis of the DAC policy. FPRI.SPRIV
is relevant as it defines which privileges are enabled for
any user. F.IA.CNF and F.AUD.CNF are relevant I&A
data and the audit trail are subject to the DAC policy.
FDP.ACF.1.3 F.DAC.POL
F.PRI.SPRIV
F.AUD.CNF
F.DAC.POL c) specifies access to objects based on ena-
bled system privileges. F.DAC.POL d) and e) cover
access as the special users SYSDBA and SYSOPER.
F.SPRIV is relevant as it defines which privileges are
enabled for any user. F.AUD.CNF is relevant as the audit
trail is subject to the DAC policy
FDP.ACF.1.4 N/A This SFR does not claim any functionality. It is included
for compliancy with the CC.
FDP.RIP.1.1 F.DAC.OR F.DAC.OR satisfies FDP.RIP.1.1 directly.
FMT.MSA.1.1 F.APR.GOP
F.APR.ROP
F.APR.GRSP
F.APR.GRR
F.APR.GOP and F.APR.ROP cover FMT.MSA.1.1 a)
which is concerned with modifying object privileges.
F.APR.GRSP covers FMT.MSA.1.1 b) which is con-
cerned with modifying system privileges. F.APR.GRR
covers FMT.MSA.1.1 c) which is concerned with modi-
fying roles.
FMT.MSA.3.1 F.DAC.POL
F.PRI.SPRIV
F.DAC.POL and F.PRI.SPRIV implicitly include restric-
tive default values. If a user has not been explicitly
granted the necessary privilege or a role containing the
required privilege then the requested action will not suc-
ceed.
FMT.MSA.3.2 F.DAC.OBA
F.DAC.POL
F.APR.GOP
F.APR.ROP
F.APR.GRR
Unless access to an object has been explicitly granted, as
described in F.DAC.OBA, F.APR.GOP, F.APR.ROP
and F.APR.GRR, no access will be allowed. On object
creation no object privileges are granted and it is not pos-
sible to configure this to be the case. F.DAC.POL is rele-
vant as it enforces the database object access SFP.
FMT.MTD.1.1 F.IA.ATT
F.LIM.CNF
F.APR.GOP
F.APR.ROP
F.APR.GRSP
F.APR.GRR
F.AUD.ACC
F.AUD.DEL
These TOE security functions are concerned with the
modification of TSF data (security attributes and audit
data). This data is stored in the data dictionary and is pro-
tected from unauthorised access by the same mechanism
as all other data in the database. F.IA.ATT and
F.LIM.CNF cover identification and authentication, and
resource limit attributes. F.APR.* cover privilege and
role TSF data. F.AUD.* cover audit data.
FMT.REV.1.1 F.LIM.CNF
F.APR.ROP
F.APR.GRSP
F.APR.GRR
Only suitably privileged users can revoke (or modify) the
following attributes: resource limits (F.LIM.CNF),
object privileges (F.APR.ROP), system privileges
(F.APR.GRSP) and roles (F.APR.GRR).
FMT.REV.1.2 F.PRI.SPRIV Directly granted privileges and roles are revoked imme-
diately. This is more rigorous than SFR FMT.REV.1.2.
Revocation of roles takes effect when a role is re-enabled
in the current session or a new user session is created.
SFR
TOE
Security
Functions
Rationale
Table 7: TOE Security Function Suitability and Binding
Oracle Common Criteria Security Target 47
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
FMT.SMR.1.1 F.IA.UID
F.IA.CSA
F.IA.CSN
F.APR.GRR
F.PRI.PRX
F.IA.UID, F.IA.CSA and F.IA.CSN in combination
ensure that the TSF maintains normal database users and
database administrative users. F.APR.GRR covers data-
base roles defined by a suitably privileged user.
F.PRI.PRX covers database roles available to a proxy
user session.
FMT.SMR.1.2 F.IA.CSA
F.APR.DER
F.APR.EDR
F.APR.DER and F.APR.EDR covers granting database
roles to database users. F.IA.CSA is relevant specifies
how to allow a user to connect as one of the special
administrative users SYSDBA and SYSOPER.
FPT.RVM.1.1 F.IA.IDE
F.DAC.POL
F.IA.IDE ensures that the TOE always knows who the
current user is. F.DAC.POL ensures then that the data-
base access control policy is upheld for this user.
FPT.SEP.1.1 F.IA.IDE
F.DAC.SEP
F.IA.IDE ensures that the identity of the user associated
with each interaction with the TOE is clear. F.DAC.SEP
ensures that the interactions between different users and
the TOE cannot interfere with each other. Additionally
there is no way to access the TOE except through the
evaluated interfaces described by the TOE security func-
tions.
FPT.SEP.1.2 F.IA.IDE
F.DAC.SEP
F.IA.IDE ensures that the identity of the user associated
with each interaction with the TOE is clear. F.DAC.SEP
ensures that the interactions between different users and
the TOE cannot interfere with each other.
FRU.RSA.1.1 F.LIM.CNF
F.LIM.POL
F.LIM.NSESS
F.LIM.TIME
F.LIM.RSESS
F.LIM.RCALL
F.LIM.CNF covers configuration of the resource quotas.
F.LIM.POL, F.LIM.NSESS, F.LIM.TIME,
F.LIM.RSESS and F.LIM.RCALL enforces the resource
quotas configured.
FTA.MCS.1.1 F.LIM.NSESS F.LIM.NSESS directly satisfies FTA.MCS.1.2
FTA.MCS.1.2 F.LIM.NSESS
F.LIM.POL
As with FTA.MCS.1.1 except that F.LIM.POL ensures
that the default number of concurrent sessions allowed is
enforced if a user specific configuration has not been
specified.
FTA.TSE.1.1 F.IA.CSN
F.IA.CSA
F.IA.CSN and F.IA.CSA define the pre-requisites for
session establishment, including possession of the CRE-
ATE SESSION privilege and being identified as a SYS-
DBA/SYSOPER, respectively. These are configured on
the basis of individual user identity. Therefore, it is pos-
sible to deny access based on user identity.
FAU.GEN.1.1 F.AUD.SOM
F.AUD.SEV
F.AUD.ALW
The database audit functionality is always active.
Whether or not, auditing is actually performed is depend-
ent on configuration of a parameter in the init.ora file
which is controlled by the OS. F.AUD.SOM,
F.AUD.SEV and F.AUD.ALW ensure all actions config-
ured to be audited are audited.
FAU.GEN.1.2 F.AUD.INF F.AUD.INF directly satisfies FAU.GEN.1.2
SFR
TOE
Security
Functions
Rationale
Table 7: TOE Security Function Suitability and Binding
48 Oracle Common Criteria Security Target
Oracle 8i Release 3 (8.1.7)
April 2001
Issue 0.9
PP Claims Rationale
Chapter 5 lists all of the SFRs included in this security target; this list includes all of
the SFRs identified in the DBMS PP. All of the operations applied to the SFRs are in
accordance with the requirements of the DBMS PP.
FAU.GEN.2.1 F.AUD.INF F.AUD.INF directly satisfies FAU.GEN.2.1
FAU.SAR.1.1 F.AUD.ACC F.AUD.ACC directly satisfies FAU.SAR.1.1
FAU.SAR.1.2 F.AUD.VIEW F.AUD.VIEW directly satisfies FAU.SAR.1.2
FAU.SAR.3.1 F.AUD.VIEW
F.AUD.ACC
F.AUD.VIEW directly satisfies FAU.SAR.3.1, addition-
ally F.AUD.ACC determines which records are available
to the user for selection.
FAU.SEL.1.1 F.AUD.SOM
F.AUD.SEV
F.AUD.ALW
F.AUD.CNF
F.AUD.SEV and F.AUD.CNF allow a suitably privi-
leged user to configure exactly which events should be
audited. F.AUD.SOM and F.AUD.ALW specify events
that are always audited. Note that for audit records data-
base subjects are always the database users, so that for
example an audit record generated by a stored procedure
will be generated with the username of the invoker, not
that of the procedure or the procedure owner.
FAU.STG.1.1 F.AUD.DEL F.AUD.DEL directly satisfied FAU.STG.1.1.
FAU.STG.1.2 F.AUD.DEL F.AUD.DEL protects audit records from unauthorised
modification or deletion.
FAU.STG.4.1 F.AUD.FULL F.AUD.FULL directly satisfies FAU.STG.4.1
SFR
TOE
Security
Functions
Rationale
Table 7: TOE Security Function Suitability and Binding
Oracle Common Criteria Security Target 49
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
A N N E X
A References
[AD] Oracle8i Architectural Design, Oracle Corporation.
[ADG] Oracle8i Application Developer’
s Guide, Oracle Corporation.
[CC] Common Criteria for Information Technology Security Evaluation,
Version 2.1, ISO/IEC 15408, CCIB-99-031, 032 & 033, August 1999.
[CM] Oracle8i Configuration Management Plan, Oracle Corporation.
[DD] Oracle8i Detailed Design Amendments, Oracle Corporation.
[DPP] Database Management System Protection Profile (DBMS PP), Issue 2.1, Oracle Cor-
poration, May 2000.
[ECD] Oracle8i Release 3 (8.1.7) Evaluated Configuration Document, Oracle Corporation.
[ERR] Oracle8i Error Messages, Oracle Corporation.
[FS] Oracle8i Functional Specification, Oracle Corporation.
[GA] Oracle8i Administrator and User Guidance Analysis, Oracle Corporation.
[ICG] Oracle8i Installation and Configuration Guide, Oracle Corporation.
[ITSEC] Information Technology Security Evaluation Criteria, Issue 1.2, Commission of the
European Communities, 28 June 1991.
[MEMO 1] CESG Computer Security Memorandum No. 1 - Glossary of Computer Security
Terms, Issue 2.0, November 1989.
[OSD] Oracle8i Operating System Dependencies, Release 8.1.7, Oracle Corporation.
[OSQM] Oracle UK Ltd Shipping Quality Manual, Oracle Corporation.
50 Oracle Common Criteria Security Target
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
[PLS] PL/SQL User’
s Guide and Reference, Release 8.1.7, Oracle Corporation, A54654-01,
June 1997.
[PRP] Oracle8i Product Release Process, Oracle Corporation.
[SAD] Oracle8i Administrator’
s Guide, Release 8.1.7, Oracle Corporation.
[SCN] Oracle8i Concepts, Release 8.1.7, Oracle Corporation. Volumes 1 & 2.
[SD1] Oracle8i Server Distributed Database Systems, Release 8.1.7, Oracle Corporation.
[SODE] Security of the Oracle Development Environment, Oracle Corporation.
[SOF] Strength of Functions Analysis, Oracle Corporation.
[SPM] Oracle8i Security Policy Model, Oracle Corporation.
[SQL] Oracle8i Server SQL Reference, Oracle Corporation. Volumes 1 & 2.
[SQL92] Database Language SQL, ISO/IEC 9075:1992 and ANSI X3.135-1992,
[SRB] Oracle8i System Release Bulletin, Oracle Corporation.
[SRC] Oracle8i Source Code, Oracle Corporation.
[SRF] Oracle8i Server Reference, Oracle Corporation.
[TCSEC] Trusted Computer Security Evaluation Criteria, Department of Defense, United
States of America, DoD 5200.28-STD, December 1985.
[TP] Oracle8i Test Plan, Procedures, Results, and Analysis, Oracle Corporation.
[VA] Oracle8i Vulnerability Analysis, Oracle Corporation.
Oracle Common Criteria Security Target 51
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
A N N E X
B Glossary
Acronyms
DAC Discretionary Access Control
DDL Data Definition Language
DES Data Encryption Standard
DML Data Manipulation Language
O-RDBMS Object-Relational Database Management System
SF Security Function
SFP Security Function Policy
SFR Security Functional Requirement
SOF Strength of Function
SQL Structured Query Language
TOE Target Of Evaluation
TSC TOE Scope of Control
TSF TOE Security Function
TSFI TSF Interface
52 Oracle Common Criteria Security Target
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
TSP TOE Security Policy
Terms
Data Definition Language
(DDL)
The SQL statements used to define the schema and schema objects in a database
[SQL]
Data dictionary A set of internal Oracle tables that contain information about the logical and physical
structure of the database. [SCN]
Data Encryption Standard
(DES)
A standard for encryption, FIPS PUB 46-2 and FIPS PUB 81. []
Data Manipulation Language
(DML)
The SQL statements used to query and manipulate data in schema objects [SQL]
Data server A component of a DBMS that supports concurrent access to a database by multiple
users, possibly at different nodes in a distributed environment. [ST]
Database A collection of data that is treated as a unit; the general purpose of a database is to store
and retrieve related information []
Database administrative user A database user to whom one or more administrative privileges have been granted. An
administrative privilege is any system privilege which is not CREATE SESSION.
[DPP],[ST]
Database connection A communication pathway between a user and a DBMS. [DPP]
Database link A definition of a one-way communication path from an Oracle database to another da-
tabase. [SCN]
Database non-administrative
user
A database user who only has privileges to perform operations in accordance with the
TSP. [DPP]
Database object An object contained within a database. [DPP]
Database session A connection of an identified and authenticated user to a specific database; the session
lasts from the time the user connects (and is identified and authenticated) until the time
the user disconnects. [DPP]
Database subject A subject that causes database operations to be performed. [DPP]
Database user A user who interacts with a DBMS and performs operations on objects stored within
the database. [DPP]
Discretionary Access Control Access control based on access rights granted by users other than the System Security
Officer. [MEMO 1]
Oracle Common Criteria Security Target 53
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
Instance The combination of a set of Oracle background processes and memory that is shared
among the processes. A database instance must be started (the shared memory allocat-
ed and the background processes created) by an authorised administrative user before
the database managed by the instance can be accessed. [SCN]
Interface product A TOE component that resides in a user process and can be used to communicate with
an Oracle database server in a secure manner. [ST]
Object An entity within the TSC that contains or receives information and upon which sub-
jects perform operations. Objects are visible through the TSFI and are composed of
one or more TOE resources encapsulated with security attributes. [CC], [SQL]
Object-Relational Database
Management System
(ORDBMS)
A DBMS that supports object-oriented technology as well as relational databases.
[SCN]
Owner The owner of a named database object is the database user who is responsible for the
object and may grant other database users access to the object on a discretionary basis.
[DPP]
Normal User A database user who was created using the CREATE USER command. This includes
the users SYS and SYSTEM but excludes the SYSOPER and SYSDBA users.
Platform The combination of software and hardware underlying the DBMS. [ST]
Privilege A right to access objects and/or perform operations that can be granted to some users
and not to others. [DPP]
Privilege, database
administrative
A privilege authorising a subject to perform operations that may bypass, alter, or indi-
rectly affect the enforcement of the TSP. [DPP]
Privilege, database object
access
A privilege authorising a subject to access a named database object. [DPP]
Privilege, directly granted An Oracle system or object privilege that has been explicitly granted to a user. Priv-
ileges granted to any roles the user has been granted are not included in the set of di-
rectly granted privileges. [SCN]
Privilege, object An Oracle privilege that allows users to perform a particular action on a specific sche-
ma object. Oracle object privileges are database object access privileges. [SCN]
Privilege, system An Oracle privilege that allows users to perform a particular system-wide action or a
particular action on a particular type of object. Some Oracle system privileges are da-
tabase administrative privileges. [SCN]
Program unit A PL/SQL program; a procedure, function, or package. [PLS]
Role (CC) A predefined set of rules establishing the allowed interactions between a user and the
TOE. [CC]
Role (Oracle) A named group of related system and/or object privileges that can be granted to users
or to other roles. [SCN]
54 Oracle Common Criteria Security Target
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
Schema A collection of logical structures of data (schema objects), owned by a specific data-
base user. [SQL]
Security attribute Information associated with subjects, users, and/or objects which is used for the en-
forcement of the TSP. [CC]
Security domain The set of objects that a subject has the ability to access. [TCSEC]
Security Function (SF) A part or parts of the TOE which have to be relied upon for enforcing a closely related
subset of the rules from the TSP. [CC]
Security Function Policy
(SFP)
The security policy enforced by a SF. [CC]
Security Functional
Requirement (SFR)
A security functional requirement defined in a protection profile or security target.
[CC]
Server process An Oracle process that services requests for access to an Oracle database from con-
nected user processes. [SCN]
SOF-high A level of the TOE strength of function where analysis shows that the function pro-
vides adequate protection against deliberately planned or organised breach of TOE se-
curity by attackers possessing a high attack potential. [CC]
SQL statement A string of SQL text containing a command and supporting clauses. All access to an
Oracle database is via SQL statements. [SCN]
Strength of Function (SOF) 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. [CC]
Structured Query Language
(SQL)
A standardised database access language; Oracle8 SQL is a superset of the ANSI/ISO
SQL92 standard at entry level conformance. [SQL]
Subject An entity within the TSC that causes operations to be performed. [CC]
System A specific IT installation, with a particular purpose and operational environment [CC]
Target Of Evaluation (TOE) The product or system being evaluated. [CC]
TOE resource Anything usable or consumable in the TOE. [CC]
TOE Scope of Control (TSC) The set of interactions which can occur with or within a TOE and are subject to the
rules of the TSP. [CC]
TOE Security Function (TSF) A part of the TOE that either directly enforces or contributes to the enforcement of the
TSP. [CC]
TOE Security Policy (TSP) A set of rules that regulate how assets are managed, protected and distributed within
a TOE. [CC]
TSF Interface (TSFI) A set of interfaces, whether interactive (man-machine interface) or programmatic (ap-
Oracle Common Criteria Security Target 55
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
plication programming interface), through which TOE resources are accessed, medi-
ated by the TSF, or information is obtained from the TSF. [CC]
User Any entity (human or machine) outside the TOE that interacts with the TOE. [CC]
User process A process that requests services, on behalf of a user or application, from an Oracle
server process. [SCN]
56 Oracle Common Criteria Security Target
Oracle8i Release 3 (8.1.7)
April 2001
Issue 0.9
This Page Intentionally Blank