9 Security Considerations

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

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:

• Batch, TSO, or POSIX address space running an Oracle tool or utility or a customer-written Oracle application

• CICS TS or IMS TM region running transactions which access an Oracle database

• Local Oracle database instance that is accessing another local or remote Oracle instance through a database link

• Oracle Network Service accessing a local Oracle instance on behalf of remote (inbound) client applications or database links

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.

• The name structure for the normal application bind resource profile is:

  ssn.service.UBIND
  

  where ssn is the OSDI subsystem name, service is the target service name, and UBIND is a constant indicating application binds.

• The name structure for the managed binds used by CICS TS, IMS TM, Oracle database links, and Oracle Net is:

  ssn.service.ABIND
  

  where ssn is the OSDI subsystem name, service is the target service name, and ABIND is a constant indicating managed binds.

  Note:

  In addition to subsystem-level authentication of binds, an OSDI database instance uses SAF to control access to the Oracle database's SYSOPER and SYSDBA system privileges. This mechanism is discussed in the following section.

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:

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.

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 user logs on to the operating system and is authenticated by normal operating system security. When the user runs an Oracle tool or application, it logs on to Oracle with "/" (a single forward slash) instead of specifying an Oracle userid and password. Oracle takes the user's z/OS userid as the Oracle userid (possibly with a prefix, specified as the OS_AUTHENT_PREFIX init.ora file parameter). This means the user can access Oracle only with z/OS userids for which the password is known. This technique is normally used only when the user is running on the same z/OS system as the Oracle server being accessed. Although it can be enabled for use over Oracle Net, doing so is not considered secure because the server cannot guarantee that the associated userid was authenticated.

• The user runs an Oracle tool or application that logs on to the Oracle server with an explicit userid/password. The verification of the userid and password is controlled by the LOGON_AUTH database region parameter, which can specify one of three verification choices:

  No SAF check. If a user defined to Oracle as IDENTIFIED EXTERNALLY attempts to logon with an explicit userid/password, the logon is rejected.

  Built-in SAF check. This built-in SAF check verifies that the userid and password that are provided on the logon are valid. The user need not be logged on to z/OS with the same userid and in fact may be running on a non-z/OS platform (connecting via Oracle Net). The Oracle userid must be defined to the z/OS security subsystem and the given password must be correct for the logon to succeed. A RACROUTE VERIFY function is performed by the OSDI code, but no logon exit is called in this case. SAF interfaces with any security manager that you have installed (IBM's RACF, CA's Top Secret or ACF2, an internally developed security manager, or another third-party security manager). This SAF check is designed to work with virtually any security manager and eliminates the need for an external logon exit, unless you want to modify the normal RACROUTE VERIFY of a userid and password.

  External logon exit. This method calls an external, dynamically loaded logon exit. Oracle Corporation supplies a sample logon exit (which does what the built-in SAF check does), or you can write your own. This exit performs the actions that you specify and then returns success or failure of the validation.

  Note:

  The supplied sample logon exit and the built-in SAF check are functionally equivalent. Unless site-specific changes to the sample logon exit are needed, the built-in SAF check should be used because it is more efficient.

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:

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:

• call a security manager (SAF calls, RACF, Top Secret, ACF2, and so forth)

• get and free storage using the STORAGE macro (the exit must keep track of all acquired storage and must make certain to free it before exiting)

• call SMF to write SMF records

• call WTO to write messages to the console

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.