Skip Headers
Oracle® Database System Administration Guide
10g Release 2 (10.2) for IBM z/OS (OS/390)

Part Number B25398-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

9 Security Considerations

This chapter describes postinstallation and operational z/OS security issues in Oracle Database for z/OS, Oracle Net, and associated products and features on z/OS. The information is presented with the assumption that IBM z/OS Security Server (RACF) is being used, but any z/OS product that fully implements IBM's System Authorization Facility (SAF) can be used. If your installation does not use RACF, please refer to your security product's documentation for matters presented here in RACF terms.

The following topics are included:

9.1 Overview

Oracle products and OSDI interface in a number of places with native z/OS security features. Some of the resulting interactions are discussed as installation topics in the Oracle Database Installation Guide for IBM z/OS. These topics include RACF resource class considerations, Program Properties and APF authorization requirements for Oracle product modules, and requirements for associating z/OS userids with OSDI-defined services.

9.2 Controlling Access to OSDI Subsystem Commands

OSDI subsystem command processing includes an authorization check to confirm that the console or the user is allowed to issue the command. You control access to commands by defining resource profiles to the security subsystem and then by granting access (for specific consoles and users) to those resources. If you do not define resource profiles, then the authorization check returns a "resource unknown" indication to OSDI, and OSDI then allows the command to be processed. Thus, the default behavior (in the absence of any profile definitions) is that any command is allowed from any source. This is not chaotic, as it may sound, because access to command-issuing mechanisms themselves (such as consoles) is usually controlled in most z/OS installations. Base your decision to define profiles and to activate the authorization mechanism upon the security standards and procedures at your installation.

The resource profiles that are used to protect commands should be defined in the resource class that you chose when installing Oracle software, as discussed in Oracle Database Installation Guide for IBM z/OS. If you elected to accept the default, then this will be the FACILITY class. Otherwise it will be a class name that you chose and configured for your SAF-compliant security software.

The command authorization resource names are of the form:

ssn.cmdverb

where ssn is the OSDI subsystem name, and cmdverb is the full-length OSDI command verb. (Verb abbreviations, such as DEF for DEFINE, must not be used in the resource name.)

The level of authorization that must be granted to users or to consoles in order to enable commands depends on the command. The following table lists all of the command verbs and the authorization level required for each:

Command Verbs And Their Required Authorization Levels

Table 9-1 Command Verbs And Their Required Authorization Levels

Command Verb Authorization Level

DEFINE

Update

ALTER

Control

SHOW

Read

START

Read

DISPLAY

Read

DRAIN

Read

RESUME

Read

STOP

Read


9.3 Controlling Access to OSDI Services

OSDI bind processing, which establishes connections between z/OS address spaces, performs an authorization check to confirm that the binding address space (the "client") is allowed to access the target service. The target service can be an Oracle Database for z/OS instance or an Oracle Net network service running on z/OS. The possible client address spaces are as follows:

The bind authorization check applies in all of these cases. In order for the check for a given target service to be meaningful, resource profiles must be defined to a SAF-compliant security server such as RACF. The profile names incorporate the OSDI service name so that access to each service is separately controlled. When profiles are defined, the z/OS userid that is associated with the client address space must have READ authorization on the target service's profile in order for the bind to be allowed. Two profiles are defined for each service: one for normal application binds (used by batch, TSO, andPOSIX Oracle tools or applications) and one for managed binds (used by CICS TS and IMS TM, and by the Oracle server and Oracle Net when operating as clients as described above).

If you do not define resource profiles for a service, then all binds from all address spaces are permitted. Oracle Corporation recommends that you define resource profiles for all services so that bind access is controlled via standard z/OS security mechanisms.

The resource profiles that are used to protect binds should be defined in the resource class that you chose when installing Oracle software, as discussed in Oracle Database Installation Guide for IBM z/OS. If you elected to accept the default, then this will be the FACILITY class. Otherwise it will be a class name that you chose and configured for your SAF-compliant security software.

9.4 Controlling Access to Database SYSDBA and SYSOPER Privileges

SYSOPER and SYSDBA are access privileges that are associated with an Oracle database instance. A database session with these privileges can perform operating functions such as starting up and shutting down the database and can perform DBA activities such as managing database and tablespace definitions. The privileges can be requested by including "AS SYSOPER" or "AS SYSDBA" in a CONNECT statement issued to a tool such as SQL*Plus.

For local clients connecting from batch, TSO, or POSIX address spaces through cross-memory, access to the SYSDBA and SYSOPER privileges is controlled using SAF-defined resources on z/OS. These must be defined in the same resource class that you use for binds, as discussed in the previous section. You chose this class when installing Oracle software, as discussed in the Oracle Database Installation Guide for IBM z/OS. If you elected to accept the default during installation, then this will be the FACILITY class. Otherwise, it will be a class name that you chose and configured for your SAF-compliant security software. The form of the resource names is:

ssn.service.OPER
ssn.service.DBA

where:

Table 9-2 Variable Definitions for Code Example

Variable Definition

ssn

is the OSDI subsystem name

service

is the database service name

OPER

is a suffix to be entered exactly as shown

DBA

is a suffix to be entered exactly as shown


After the resources are defined, granting "read" authorization on a resource to a given z/OS userid allows a job or session with that userid to connect to the database with the given privilege. You must grant read authority on the OPER resource to the z/OS userids that will startup and shutdown the database.

If you do not define these resource names for a given database instance, then any userid is allowed to connect with SYSOPER or SYSDBA privileges. Oracle Corporation recommends that you define these resources so that the use of Oracle database system privileges is controlled.

If you want remote clients to have access to SYSDBA and SYSOPER privileges, you must create an Oracle password file using the ORAPWD utility described in Chapter 7, "Oracle Database Administration Utilities". SAF authorization cannot be used for remote clients because the user's OS userid cannot be verified and might not even be compatible with SAF expectations.

A separate file is used to provide password verification for remote users because the database may not be mounted or open when the connection is requested. (This occurs when the remote user connects in order to issue STARTUP, for example.)

To use an Oracle password file to control remote client access to SYSOPER and SYSDBA privileges, follow these steps:

  1. Create and initialize a password file as described in the section "Oracle Password Utility (ORAPWD) on z/OS".

  2. Add an ORAPASSW DD statement to the database service region JCL procedure. Specify the dsname of the VSAM linear data set created in step 1, and specify DISP=SHR.

  3. Shut down the Oracle instance and stop the associated service.

  4. Set the REMOTE_LOGIN_PASSWORD_FILE parameter to EXCLUSIVE in the instance's init.ora parameter file.

  5. Restart the database service (with the updated JCL procedure) and startup the Oracle instance.

9.5 Database Service Actions Subject to z/OS Authorization

When a database service runs on z/OS, some of its interactions with the operating system may be subject to authorization checks. These checks are performed by the operating system, not by Oracle software, and generally are based on the z/OS userid associated with the service address space. The Oracle Database Installation Guide for IBM z/OS describes the z/OS mechanisms that are used to associate a particular userid with a service address space. This section describes the actions that the Oracle server and the OSDI infrastructure take that might be subject to authorization checks on your system. It is your responsibility to make sure that a z/OS userid is associated with a database service, if necessary, and that it has the correct authorizations for the functions it must perform.

Data Set Creation and Deletion

The Oracle server can invoke the z/OS IDCAMS utility to create and to delete VSAM LDS files. Details regarding when this occurs and how you control it are provided in Chapter 4, "Defining z/OS Data Sets for the Oracle Database". If your server will be creating or deleting files, make sure that the associated z/OS userid has the necessary authorization to do so with the data set name structure that you are using.

Data Set Open

The Oracle server performs an update-type open on the VSAM LDS files comprising the database. It also opens the alert log and other diagnostic logs for output and opens various parameter and SQL files (such as the SQLBSQ and ORA$FPS DDs) for input. The associated z/OS userid must have the required authorization for these opens.

OSDI Bind Authorization

Database links are Oracle's mechanism for distributed database access. When an Oracle application uses a database link, a connection is made from one Oracle database instance to another. When this happens on z/OS, an OSDI bind is issued from the first instance to the second (if the second instance is on the same z/OS system) or from the first instance to an Oracle Net network service (if the second Oracle instance is remote). If you are using OSDI bind authorization checking as described previously in the section "Controlling Access to OSDI Services", the z/OS userid that is associated with the first instance must be authorized to bind to the second instance or to Oracle Net.

UNIX System Services Access

Certain Oracle Database for z/OS features (such as the UTL_FILE and UTL_HTTP packages, Oracle JVM, and the Oracle external table feature) use UNIX System Services. To use UNIX System Services, the database service must have an associated z/OS userid, and that userid must have a default OMVS segment defined to the security system. If either of these conditions is not met, then message MIR0110W is issued during service address space initialization, and the features which rely on UNIX System Services are inoperative in that Oracle instance.

9.6 External Data Mover Actions Subject to z/OS Authorization

When you use Oracle Recovery Manager (RMAN) to perform backup or recovery actions on Oracle Database for z/OS, one or more separate External Data Mover (EDM) address spaces may be started to perform data movement and backup management tasks. The details of this activity are in Chapter 6, "Database Backup and Recovery". Although it is not defined as an OSDI service, the EDM runs as a system address space and can have an associated z/OS userid via the same mechanisms as OSDI services.

The EDM address space must have the necessary authorization to open sequential backup file data sets for output (during backup) or for input (during recovery). Certain RMAN backup maintenance activities cause the EDM to delete backup data sets via an IDCAMS DELETE command, so the EDM that is used during backup maintenance should have that authorization as well.

Note:

Be aware that for backup and restore operations, the EDM address space does not open or access the associated Oracle database (VSAM LDS) files. Those files are accessed only in the Oracle server address space.

9.7 Oracle Net Actions Subject to z/OS Authorization

The Oracle Net network service JCL procedure name must have an associated z/OS userid. The associated z/OS userid must have an OMVS RACF segment (or equivalent, if a product other than RACF is used) if the installation is not using a default OMVS segment.

9.8 Client Authorizations

IBM's TCP/IP protocol makes use of z/OS UNIX System Services. A z/OS address space that uses IBM TCP/IP must therefore be a UNIX System Services process or be capable of being dubbed. Dubbing occurs automatically when needed, but it requires the z/OS userid associated with the address space to have a default UNIX System Services segment defined in the security subsystem (for example, RACF). If dubbing fails, the network connection will not be opened and the application probably will not succeed. You must ensure that all z/OS clients that connect to remote Oracle servers can be dubbed. If in doubt, contact your z/OS security administrator.

9.9 Authorizing Oracle Logon

When an Oracle userid is defined as IDENTIFIED EXTERNALLY it means the user is authenticated by operating system facilities rather than by Oracle. On z/OS, this mechanism works in one of two ways:

The built-in SAF check and the external logon exit are called only for users that are IDENTIFIED EXTERNALLY. These checks are not performed for a user who is defined to Oracle (IDENTIFIED BY <password>), because these users can be resolved internally within Oracle.

The type of validation done for users that are IDENTIFIED EXTERNALLY is indicated in the OSDI service parameters. A single parameter controls this validation. The syntax is:

LOGON_AUTH (auth)

where auth is:

NONE - explicit specification of userid/password not allowed

SAF - perform built-in SAF check

exitname - call logon exit

The default (if nothing is specified) is NONE.

For example:

LOGON_AUTH(NONE) 
LOGON_AUTH(SAF) 
LOGON_AUTH(RACFSMPO) 

The logon exit must reside in the STEPLIB or JOBLIB concatenation or in the linklist, and it must be in an authorized library.

A sample user logon exit is provided in Oracle SRCLIB library member RACFSMPO. It uses the z/OS SAF interface to invoke the z/OS security manager. If the z/OS security manager does not support the SAF interface, then the calls to RACROUTE in the exit must be replaced with the equivalent calls appropriate for the z/OS security manager.

The calling sequence for the logon exit uses standard z/OS assembler calling conventions. R15 is the entry point, R14 is the return address, R13 points to a standard 72-byte save area, and R1 is the address of a parameter list. The parameter list consists of a list of addresses of each parameter (all values are passed by reference, not by value), and the last parameter has the high-order bit set.

When returning, R15 should be set to 0 to indicate a successful verification of the userid and password that were supplied, and should be set to any nonzero value to indicate any type of failure (four would be an appropriate value).

The exit is called in 31-bit addressing mode, supervisor state, storage protection key 7, and in an authorized address space. The exit will be running in TCB mode with no locks held and with no ARRs, FRRs, or EUT-style FRRs set. The exit is called in primary addressing mode with HASN=PASN=SASN (home, not cross memory mode).

The logon exit should be fully reentrant code.

The parameter list that is passed contains pointers to the following parameters, all of which are input only:

Table 9-3 Input-Only Parameters

Field Type/Length Description

work area

char/4k

set to all x'00' before every call to the exit

userid

char/1+

userid to be validated (number of bytes varies)

userid length

bin/2

length of userid

password

char/1+

password to be validated (number of bytes varies)

password length

bin/2

length of password

z/OS jobname

char/8

z/OS jobname from JOB card of client

ASID

bin/2

address space id of client address space

OSDI session id

bin/4

a unique OSDI session id

OS username

char/8

the operating system username (batch, TSO, CICS, and IMS only)

terminal name

char/8

terminal name

program name

char/8

program name

RACF group name

char/8

RACF group name

connection type

char/8

connection type (BATCH, TSO, CICS, IMS, TCP/IP, VTAM) to indicate environment of client

JES jobid

char/8

JES job identifier (such as JOB08237)

job card entry time

bin/4

entry (submission) time of job. Binary hundredths of a second since midnight

job card entry date

packed/4

entry (submission) date of job. Packed decimal 0CYYDDDF, where C=0 FOR 19, C=1 FOR 20, YY=year, DDD=day number within the year (Jan 1=1)

job card accounting info

char/145

from jobcard

network data (high bit set in parameter list)

char/2+

variable length NIV data (refer to Chapter 10, "Oracle SMF Data")


The only output of the logon exit is the R15 return code. No other value that is passed in the parameter list should be modified except the first one.

The first parameter is a 4096-byte work area that is set to all x'00' before every call to the logon exit. The logon exit can use this storage for anything that it needs. It should not be freed.

The logon exit can do any of the following:

The logon exit should not do anything that would cause it to wait for any significant period of time (more than one tenth of a second, for example). Avoid opening data sets, writing to the operator with a reply (WTOR), and creating enqueues.

Any resources that are acquired in the logon exit must be freed before it returns. There is no cleanup call made to the logon exit, so any resources that are not released will accumulate in the address space and could eventually cause resource shortages.