Source: http://docplayer.net/953183-Security-target-for-security-evaluations-oracle-corporation-500-oracle-parkway-redwood-shores-ca-94065.html
Timestamp: 2018-02-21 19:48:37
Document Index: 83832534

Matched Legal Cases: ['art 2', 'art 3', 'art 2', 'art 3', 'art 2', 'art 2', 'art 1', 'art 2']

Security Target for. Security Evaluations Oracle Corporation 500 Oracle Parkway Redwood Shores, CA PDF
Download "Security Target for. Security Evaluations Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065"
1 Security Target for Oracle Database 11g Release 2 ( ) Standard Edition and Standard Edition One October 2011 Version 1.3 Security Evaluations Oracle Corporation 500 Oracle Parkway Redwood Shores, CA Security Target for Oracle Database 11g 1 Release 2 ( ) Standard Edition and Standard Edition One
2 Security Target for Oracle Database 11g Standard Edition and Standard Edition One Release 2 ( ) Author: Helmut Kurth Contributors: Shaun Lee, Petra Manche Copyright 1999, 2011, Oracle Corporation. All rights reserved. This documentation contains proprietary information of Oracle Corporation; 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 , Rights in Technical Data and Computer Software (October 1988). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 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 is a registered trademark and Oracle Database 10g, Oracle9i, PL/SQL, Oracle Enterprise Manager, Oracle Call Interface, SQL*Plus, SQL*Loader and Oracle Net are trademarks or registered trademarks of Oracle Corporation. Other names may be trademarks of their respective owners. 2 Security Target for Oracle Database 11g Release 2 (11.2.0) Standard Edition and Standard Edition One
3 Contents 1 Introduction... 5 ST Reference... 5 TOE Reference... 5 TOE Overview... 6 TOE Product Components... 7 Document Overview... 8 Conformance Claims... 8 Conformance Rationale TOE Description Oracle Database 11g R2 Architecture An Oracle Database Access Control Quotas Identification and Authentication Auditing Security Management Consistency of Replicated TSF Data Secure Distributed Processing Other Oracle Database 11g Security Features Security Problem Definition Threats Organisational Security Policies Assumptions Security Objectives TOE Security Objectives Environmental Security Objectives Security Objectives Rationale IT Security Requirements TOE Security Functional Requirements TOE Security Assurance Requirements Security Requirements Rationale Assurance Measures Rationale Security Target for Oracle Database 11g 3 Release 2 ( ) Standard Edition and Standard Edition One
4 6 TOE Summary Specification TOE Security Functionality Security Mechanisms and Techniques Assurance Measures TOE Summary Specification Rationale A References B Glossary Acronyms Terms Security Target for Oracle Database 11g Release 2 (11.2.0) Standard Edition and Standard Edition One
5 CHAPTER 1 Introduction This document is the Security Target for the Common Criteria evaluation of Oracle Database 11g Release 2 ( ) Standard Edition and Standard Edition One. ST Reference TOE Reference Title: Security Target for Oracle Database 11g Release 2 Standard Edition and Standard Edition One, Version 1.3. Target of Evaluation (TOE): Oracle Database 11g Standard Edition and Standard Edition One. Release: with all critical patch updates up to and including October 2011 via the July 2011 PSU as well as the October 2011 CPU. Note: This includes the guidance documentation which consists of [ECD] and the Oracle Database 11g Release 2 documentation library (Part No. E11882_01). Note: Oracle s release numbers are of the form a.b.c.d where a is the major release number b is the maintenance release number c is the application server release number d is the component release number In some cases there may be an additional number at the end which then defines a platform-specific release number (usually a patch set). In the case of the TOE, all components have the release number x with no platform. Operating System Platforms: Red Hat Enterprise Linux 5.5 Advanced Platform; SuSE Linux Enterprise Server 11; Oracle Enterprise Linux Version 5 Update 5. Security Target for Oracle Database 11g 5 Release 2 ( ) Standard Edition and Standard Edition One
6 TOE Overview The following overview applies to the Oracle Database 11g Release 2 Standard Edition. Standard Edition and Standard Edition One support up to 4 CPUs (including CPUs in a cluster used with Real Application Clusters). Standard Edition supports up to 1000 users, Standard Edition One supports up to to 400 users. Standard Edition and Standard Edition One support databases up to a size of 500 GB. Standard Edition One does not support Real Application Clusters Standard Edition is targeted at medium sized organizations and Standard Edition One is targeted at small to medium sized organizations. Oracle Database 11g is an object-relational database management system (ORDBMS), providing advanced security functionality for multi-user distributed database environments. The security functionality in Oracle Database 11g includes: user identification and authentication, with password management options and support for enterprise users (password option only). In the case of Enterprise Users (defined later) this function is partly provided by the IT-environment. Note that [BR-DBMSPP] defines identification and authentication as a function of the IT environment. This is the case for a DBMS that relies on the underlying operating system for the identification and authentication of the user. In the case of the Oracle DBMS the identification and authentication is either performed by the TOE in total (in the case of users that are not Enterprise Users) or performed with the assistance of an authentication server in the IT environment (in the case of Enterprise Users). In both cases it is the TOE that mediates the identification and authentication of the user; discretionary access controls on database objects, which controls access to objects based on the identity of the subjects or groups to which the subjects and objects belong, and which allows authorized users to specify how the objects that they control are protected; granular privileges for the enforcement of least privilege; user-configurable roles for privilege management, including an authorized administration role to allow authorized administrators to configure the policies for discretionary access control, identification and authentication, and auditing. The TOE must enforce the authorized administration role; quotas on the amount of processing resources a user can consume during a database session; audit capture is the function that creates information on all auditable events; extensive and flexible auditing options; secure access to remote Oracle databases; and 6 Security Target for Oracle Database 11g Release 2 (11.2.0) Standard Edition and Standard Edition One
7 stored procedures, triggers and security policies for user-defined access controls and auditing. Those functions are a superset of the security functions defined in [BR-DBMSPP], chapter 2.3. Oracle Database 11g relies on the IT-environment for the non-bypassibility and domain separation properties. Those properties need to be provided by the underlying operating systems in co-operation with the hardware platform. The operating system platforms listed above have all been evaluated for conformance to the Controlled Access Protection Profile [CAPP] which requires to enforce those properties. In addition Oracle Database 11g enforces its own separation between different users based on the functions provided by the underlying operating system. Oracle Database 11g supports both client/server and standalone architectures. In addition, Oracle Database 11g 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 Oracle Database 11g Server acts as a data server, providing access to the information stored in a database. Access requests are made via Oracle Database 11g interface products that provide connectivity to the database and submit Structured Query Language (SQL) statements to the Oracle Database 11g data server. The Oracle Database 11g 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 Oracle Database 11g includes the products identified in Table 1. Access to the Oracle Database 11g server is provided via the interface products identified in Table 2. [ECD] defines which TOE products must be installed in the evaluated configuration and defines the requirements for setting up the TOE environment. Table 1: TOE Server Products TOE Server Products Oracle Database 11g Standard Edition Oracle Database 11g Standard Edition One Table 2: TOE Interface Products TOE Interface Products SQL*Plus Oracle Call Interface Oracle Net Services Security Target for Oracle Database 11g 7 Release 2 ( ) Standard Edition and Standard Edition One
8 Document Overview This document consists of an update to the security target for Oracle11g Release 1 (11.1.0) Standard Edition and Standard Edition One, [ST11gR1-SE], which was used in the most recent Common Criteria evaluation of Oracle11g. Changes made relative to [ST11gR1-SE] are minor and are explained in the chapter on Security in [WHATSNEW]. Chapter 2 of this security target provides a high-level overview of the security features of the Oracle Database 11g R2 data server. Chapter 3 describes the security problem definition with the identification of the assumptions, threats, and security policies of the 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) and the Security Assurance Requirements (SARs). Chapter 6 summarises each Security Function (SF) provided by Oracle Database 11g R2 to meet the security requirements. Appendix A contains a list of references and Appendix B provides a glossary of the terms. Conformance Claims CC Conformance Protection Profile Conformance The CC conformance claim is: part 2 extended and part 3 conformant. This Security Target conforms to [CC, Part 2] and [CC, Part 3]. [BR-DBMSPP] contains extended SFRs which are included in this Security Target. All other SFRs in this Security Target are conformant to [CC, Part 2]. ALC_FLR.3 is the only augmented assurance criterion specified in addition to the ones in the EAL4 assurance package. Assurance: EAL4 augmented with ALC_FLR.3 1. Keywords: Oracle Database 11g R2, O-RDBMS, database, security target, EAL4 Version of the Common Criteria [CC] used to produce this document: 3.1 Release 3. Demonstrable conformance to the U.S. Government Protection Profile for Database Management Systems in Basic Robustness Environments, Version 1.3. ([BRDBMSPP]). This protection profile requires at least demonstrable conformance. Note that [BR-DBMSPP] even in version 1.3 (published in December 2010) is based on Release 1 of CC V3.1. In CC V3.1 R3 some SFR components have changed and this Security Target uses the SFR components as defined in CC V Therefore, as in the previous evaluation (which was based on CC V3.1 R2 and used version 1.2 of the Protection Profile), this Security Target can only claim demonstrable conformance. 1 ALC_FLR.3 provides assurance at the highest defined component level that there are flaw remediation procedures for the TOE by which discovered security flaws can be reported to, tracked and corrected by the developer, and by which corrective actions can be issued to TOE users in a timely fashion. 8 Security Target for Oracle Database 11g Release 2 (11.2.0) Standard Edition and Standard Edition One
9 Conformance Rationale Table 3 in chapter 5 identifies each SFR for this Security Target that was derived from [BR-DBMSPP] and the tailoring operations performed relative to [BR-DBMSPP]. The tailoring is identified in ITALICISED CAPITAL LETTERS within the text of each SFR in chapter 5. All of the tailoring operations are in conformance with the assignments and selections in [BR-DBMSPP]. Security functional requirements additional to those defined in [BR-DBMSPP] are marked bold in table 3 of chapter 5. Tailoring of those SFRs with respect to part 2 of the CC is also identified in ITALICISED CAPITAL LETTERS. There are two additional threats not listed in [BR-DBMSPP]: T.RESOURCE has been added as the threat of a single user attempting to consume database resources in a way that would prohibit other users from accessing the DBMS. T.AUDIT_COMPROMISE has been added as the threat of an unauthorized user to compromise the audit trail such that accountability of a user for his actions is no longer given. There are the following additional security objectives not listed in [BR-DBMSPP]: O.RESOURCE has been added to address the threat T.RESOURCE. O.AUDIT_REVIEW has been added to address the ability of the TOE to provide functions for authorized administartors to evaluate the audit log entries. This objective supports the organizational security policy P.ACCOUNTABILITY included in [BRDBMSPP]. Reviewing the audit records is a function [BR-DBMSPP] allows to be done in the IT-environment, but Oracle Database 10g provides its own functions to do this. O.AUDIT_PROTECTION has been added to address the ability of the TOE to protect its audit trail. While [BR-DBMSPP] allows to store the audit trail in storage managed and protected by the IT environment, Oracle Database 10g uses objects it controls itself to store the audit trail. Therefore the TOE is also responsible for the protection of the audit trail. Note that the additional objectives O.AUDIT_REVIEW and O.AUDIT_PROTECTION have been taken from [BR-MAN] with O.AUDIT_REVIEW being phrased more specific. There is an additional security objective for the IT environment, OE.DIR_CONTROL addressing the objective for a controlled directory server in the IT environment to support authentication of Enterprise Users. There is another additional security objective for the environment, OE.COM_PROT addressing the objective of securing the communication between distributed parts of the TOE and between the TOE and the external directory server. There is an additional underlying system assumption, A.MIDTIER, which is included to ensure accountability in multi-tier environments. Although the O-RDBMS can audit the actions of a proxy user, accountability relies upon the correct identity of the client (given during the connection by the middle-tier). As explained in chapter 1 Security Target for Oracle Database 11g 9 Release 2 ( ) Standard Edition and Standard Edition One
10 (TOE Overview), this type of environment is an addition to the scope of evaluation (which was first introduced for Oracle8i). An additional assumption A.COM_PROT is included to address the issue of secure communication between different parts of the TOE as well as between the TOE and the directory server. [BR-DBMSPP] does not include communication with an external directory server nor does it assume a distributed TOE. Therefore this additional assumption is related to functionality not covered by [BR-DBMSPP]. It is a refinement of the assumption A.PHYSICAL that assumes physical protection of transmitted information. A.COM_PROT generalizes this to allow also IT based protection (e. g. a cryptographically secured channel) and not only physical protection. Another additional assumption A.CLIENT_AP has been included to address the distributed nature of the TOE where client applications execute on a separate system. It is a refinement the assumption A.NO_EVIL in [BR-DBMSPP], which is related to administrators. A.CLIENT_AP refines this to include application developers that develop applications executing on the client part of the TOE Table 3 in chapter 5 lists each TOE Security Functional Requirement (SFR) included in this Security Target. These SFRs were all included in [BR-DBMSPP], with the exception of those additional SFRs marked in bold in table 3 of chapter 5. The assurance requirements specified in this security target are those for EAL4 augmented with ALC_FLR.3. This is a superset of all assurance requirements listed in [BR-DBMSPP]. The additional threats and objectives have been included to address the additional security functional requirements in the ST. Some of the additional security functional requirements address also security objectives listed in [BR-DBMSPP]. They actually address the sometimes incomplete coverage of the objectives listed in [BR-DBMSPP] by the security functional requirements listed in [BR-DBMSPP]. The rationale sections in this document will discuss this in more detail. The only difference between version 1.2 and version 1.3 of the U.S Government Protection Profile for Database Management Systems is the omission of the assumption (and the associated objective for the IT environment) that the underlying operating system is evaluated in accordance with a U.S government approved Protection Profile. 10 Security Target for Oracle Database 11g Release 2 (11.2.0) Standard Edition and Standard Edition One
11 CHAPTER 2 TOE Description Oracle Database 11g R2 Architecture This section describes the product features that provide security mechanisms and contribute to the security of a system configured using Oracle Database 11g R2. For a detailed description of the security features of Oracle Database 11g R2 the reader is referred to [SG] and [DAG, part 1, chapter 7 and part V]. 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 Oracle Database 11g R2 architecture, the types of database objects supported by Oracle Database 11g R2, 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 Oracle Database 11g R2. Additional Oracle Database 11g R2 security features that are not addressed by the security functional requirements of Chapter 5 are also briefly discussed. Database Instance The Oracle Database 11g architectural components are described in detail in [CON]. 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. An instance consists of a set of Oracle background processes, which do the work of the DBMS by executing Oracle Database 11g 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. Security Target for Oracle Database 11g 11 Release 2 ( ) Standard Edition and Standard Edition One
12 The lifetime of an 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 Distributed Databases Structured Query Language (SQL) Each database user employs Oracle Database 11g interface products to establish a database connection to an Oracle Database 11g 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 Oracle Database 11g 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. 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 Oracle Database 11g 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. The Oracle Database 11g 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 Oracle Database 11g 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, configure 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 database; Session Control statements dynamically manage the properties of a user s database session. System Control statements dynamically manage the processes and parameters of an Oracle Database 11g instance. Embedded SQL statements incorporate DDL, DML, and transaction control statements within a procedural language program. Programming Language/SQL (PL/SQL) is a procedural language supported by Oracle Database 11g that provides program flow control statements as well as SQL 12 Security Target for Oracle Database 11g Release 2 (11.2.0) Standard Edition and Standard Edition One
13 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. The flashback query feature allows data to be queried from a point in the past. Once a user has set the date and time that they would like to view, any SQL query that they execute will operate on data as it existed at that point in time. This can allow suitably authorised users to correct their own mistakes. SQL operations can be used to view the change history in order to identify the error. The error can then be backed out of by restoring data as it existed before the error. Note that the Flashback functionality does not reverse certain DDL statements such as TRUNCATE, although it can provide a way to restore accidentally dropped tables. It also does not apply to packages, procedures, or functions. Client side interfaces The Oracle Call Interface (OCI - described in [OCI]) provides an application programming interface (API) for developing database applications written in high level languages such as C. An Oracle Database An Oracle 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 [CON part I and part 2]; and non-schema objects to organise, monitor, and control the database [SQL, chapter 3]. In an Oracle database there are two types of connections for users of the database: Administrator connection. This covers users who connect to the database via AS SYSOPER or AS SYSDBA by virtue of possessing either the SYSOPER or SYSDBA system privilege (see [DAG, 1]). Users making a connection AS SYSOPER are allowed to perform operator administrative tasks (e.g. database startup and shutdown, and ALTER DATABASE commands). Users making a connection AS SYSDBA are allowed to perform all administrative tasks (including granting and/or revoking object privileges on other users objects); Normal connection (note that this includes users SYS and SYSTEM. [DAG, 1]). This covers users who are authorised to access the database by virtue of being explicitly defined and identified to an instance of the Oracle database server. Data Dictionary At the centre of an Oracle database is the data dictionary - a set of internal Oracle tables that contain all of the information the Oracle database 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. [SG, 4: Managing System Privileges] cautions that extreme care must be taken when granting roles which provide privileged access to the data dictionary. 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. Security Target for Oracle Database 11g 13 Release 2 ( ) Standard Edition and Standard Edition One
14 All of the information about database objects is stored in the data dictionary and is 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. Oracle Database 11g supports the schema object types identified in [SQL, 3] and contains the following objects Clusters Constraints Database links Database triggers Dimensions External procedure libraries Index-organized tables Indexes Indextypes Java classes, Java resources, Java sources Materialized views Materialized view logs Object tables Object types Object views Operators Packages Sequences Stored functions, stored procedures Synonyms Tables Views. A special schema PUBLIC is provided by Oracle Database 11g 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. Nonschema Objects 14 Security Target for Oracle Database 11g Release 2 (11.2.0) Standard Edition and Standard Edition One
15 [SQL, chapter 3, section Database Objects ] lists object types that can be created and manipulated with SQL, but are not contained within a schema. These include: Contexts Directories Parameter files (PFILEs) and server parameter files (SPFILEs) Profiles Roles Rollback segments Tablespaces 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 alter tablespaces for backup and recovery operations. Within the database files, Oracle Database 11g 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 Oracle Database 11g has two kinds of user connection: administrative connection (connecting AS SYSDBA or AS SYSOPER) and normal connection. Throughout this document the following terms are used to classify the types of database users: Normal User/Database Subject: A user who is connected via a normal connection. Note that the pre-defined users SYS and SYSTEM can be normal users. Database Administrative User/Administrative User: Any user who is authorised to perform administrative tasks. This term covers: A Normal User who is authorised to perform an administrative task via the possession of an administrative privilege which permits the operation of the task. A user who connects to the database via an administrative connection. Users making an administrative connection are authorised to access the database by virtue of having the SYSDBA or SYSOPER system privilege (i.e. they possess OS platform specific access rights, or are listed in the Oracle Database 11g password file as a SYSDBA or SYSOPER user). Security Target for Oracle Database 11g 15 Release 2 ( ) Standard Edition and Standard Edition One
16 Note that the word authorised is used (e.g. an authorised administrative user ) to indicate that the user 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 management options) that can be assigned to individual users. These security topics are discussed in detail in subsequent sections of this chapter. Real Application Clusters (Standard Edition only) Data Integrity Real Application Clusters (RAC) comprises several Oracle instances running on multiple clustered computers, which communicate with each other by means of a socalled interconnect. RAC uses cluster software to access a shared database that resides on shared disk. RAC combines the processing power of these multiple interconnected computers to provide system redundancy, near linear scalability, and high availability. RAC also offers significant advantages for both OLTP and data warehouse systems and all systems and applications can efficiently exploit clustered environments. Real Application Clusters is a feature now included in the evaluated configuration but is not available for Standard Edition One. All the security functions used to protect elements of an Oracle database defined in this Security Target work transparently with Real Application Clusters. Oracle Database 11g provides mechanisms to ensure that the consistency and integrity of TSF and user 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. With RAC installed each instance of RAC maintains its own copy of the system global area and the database cache, which are synchronized over the interconnect. In addition global locks on the RAC environment ensure that concurrent updates are synchronized. Those mechanisms together with the mechanisms mentioned above for transaction management and concurrency control for the database ensure the consistency and integrity of both user and TSF data in a RAC environment. Access Control Access control is the process of defining a user s ability to read or write information. For this, Oracle Database 11g provides discretionary access control (DAC). Discretionary Access Control DAC can be used to selectively share database information with other users. This access control mechanism can be used to enforce need-to-know style confidentiality 16 Security Target for Oracle Database 11g Release 2 (11.2.0) Standard Edition and Standard Edition One
17 as well as to control data disclosure, entry, modification, and destruction. In addition to the DAC controls enforced by the Oracle Database 11g server, application-specific access controls can be implemented using views and triggers to mediate a user s access to application data. The DAC mechanism controls access to database objects based on the privileges enabled in the database session. There are two types of DAC 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, authorising all database users for the privilege. During a database session, the privileges enabled in the session may be changed using several Oracle Database 11g mechanisms that affect the set of privileges held by the session. System Privileges Object Privileges Roles Oracle Database 11g 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 users may be granted more powerful system privileges to authorise them to manage administrative objects, bypass particular server access controls, or perform specialized 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). 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. Oracle Database 11g 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. Oracle Database 11g 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 Security Target for Oracle Database 11g 17 Release 2 ( ) Standard Edition and Standard Edition One
18 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. Least privilege Privilege Bracketing 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. 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 DDL Restriction 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. Note that this feature is not used to implement any security functional requirement of this Security Target. Privileges held via roles cannot be used to perform a DML operation that is required to issue a DDL statements. For example a user who receives the SELECT ANY TABLE system privilege or the SELECT object privilege for a table through a role can use neither privilege to create a view on a table that belongs to another user. The user must have directly granted privileges authorising the access to the underlying tables. Pre-defined Roles By default Oracle 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 and can be modified or removed by suitably privileged users [SG, 4]. 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 in addition to those granted to PUBLIC. The session also 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, 18 Security Target for Oracle Database 11g Release 2 (11.2.0) Standard Edition and Standard Edition One
19 Executing a stored program unit, or Firing a trigger. 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 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 Application Context 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. An application context allows an application to make security decisions based on additional attributes attached to a user s session information. An application context provides a protected session persistent storage area for additional user attributes defined by the application. To support application managed session pooling by middle tier applications, the DBMS_SESSION interface for managing application context is enhanced for Oracle Database 11g. This interface now has a client identifier for each application context so that the application context can be managed globally while each client will see only their assigned application context. Quotas Using Oracle Database 11g profiles, a database administrative user can set quotas on the amount of processing resources a user can consume during a database session. Limits can be specified for the following: enabled roles per session (via an init.ora parameter) database sessions per user, Security Target for Oracle Database 11g 19 Release 2 ( ) Standard Edition and Standard Edition One
20 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 Oracle Database 11g server will abort the operation, and, in some cases, terminate the user s session, or, in other cases, simply terminate the current SQL statement or rollback the current transaction. A database 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. Resumable statements are a feature in Oracle Database 11g which allows an administrator to temporarily suspend a large operation, such as a batch update data load. This might be necessary when space has run out. Suspending the operation gives the database administrator an opportunity to take corrective steps to resolve the error condition. After the error has been corrected, the suspended operation automatically resumes execution. A suspended resumable operation is aborted automatically if the error is not fixed within a set time period. Users must have the RESUMABLE system privilege before they can execute resumable operations. An ALTER SESSION ENABLE RESUMABLE statement is provided to enable SQL statements to be resumable when they are invoked within the session. Resumable operations are suspended under one of the conditions: Out of space, Space limit error, or Space quota error. Identification and Authentication Oracle Database 11g always identifies authorised users of an Oracle database prior to establishing a database session for the user. Authentication can be performed directly by the Oracle Database 11g 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 Oracle Database 11g 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. This form of authentication is appropriate for Oracle Database 11g only if it is running on a Microsoft Windows operating system. Since no Microsoft Windows operating system platforms are to be used for this evaluation, the TOE does not use this form of authentication. For Oracle authentication, a user must specify a user name and password in order to connect. For authentication 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. 20 Security Target for Oracle Database 11g Release 2 (11.2.0) Standard Edition and Standard Edition One
Security Target for Oracle Database 11g Release 1 (11.1.0) with Oracle Database Vault
Security Target for Oracle Database 11g with Oracle Database Vault September 2009 Version 6.0 Security Evaluations Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 Security Target for Oracle