Controlling access to RACF passwords

Installation personnel should ensure that the security of RACF® user passwords is not violated.

You should restrict the operator's use of the JES operator commands. Using JES commands, the system operator can display JES data areas that contain both the current and new RACF passwords associated with a job, even though these passwords are in a masked format. (When a user submits a job and supplies RACF passwords on the JOB statement, JES stores them for the life of the job.)

It is also possible for the operator to display password information when displaying real storage at the console. Again, the installation should monitor the operator's activities to ensure that passwords remain secure. You can monitor the operator by creating profiles for the appropriate commands in the OPERCMDS class, and requesting auditing in the OPERCMDS profiles. If the operator has the OPERATIONS attribute, you can request additional logging by issuing the SETROPTS OPERAUDIT command. This causes logging of all activity that was allowed because the user had the OPERATIONS attribute.

Also, the JES3 dump core utility allows users to view stored passwords. You should restrict access to the JES3 dump core utility.

Note: JES3 allows system programmers to specify a password for the JES3 dump core utility (not a RACF password). This password is stored in clear text in a JES3 module. You should protect this module from unauthorized use.

RACF commands that contain sensitive values, such as passwords, should not be issued on the operator's console because sensitive information will appear in SYSLOG. Also, make sure you protect the GTF trace data set if you have SET TRACE active because sensitive information might appear in the trace records that are produced.

You should restrict access to SVC dumps and standalone dumps, which might contain password information.

If users need to submit jobs for other users, activate the SURROGAT class and define profiles so that users can allow other users to submit jobs for them. In this way, a user does not need to know anyone else's password. For more information, see Surrogate job submission.

If JES support for user ID propagation is installed, batch jobs submitted by TSO users do not need any RACF identification information (user ID, group name, and password) in their JOB statements, as long as the following assumptions are true:

The TSO user is RACF-defined.
The job is submitted under the user's own user ID.
If the job is submitted on a processor that is part of an NJE (networking job entry) network, the job runs on the home (user's) node.

Note: If a user specifies //DD DATA and neglects to delimit the data (with /* or DLM specification) when submitting a batch job through a card reader or RJE work station, subsequent jobs are read as part of the user's data until a delimiter is read. You should be aware that if this situation occurs, RACF user IDs, group names, passwords, and resource names from the following job's JCL become available to the user who failed to supply a delimiter. The installation should use SMF or JES installation-written exit routines to restrict the use of the //DD DATA statement to reduce this security exposure.