JES3 uses the system authorization facility (SAF) to pass security information about jobs and resources to CA Top Secret. CA Top Secret makes access decisions based on information in its databases and passes its decision back to JES3.
The following is supported when MLS is active on an CA Top Secret system:
In addition, CA Top Secret provides additional support beyond MLS requirements. You can control what data is output to a particular device and restrict certain users to specific output devices.
Certain JES3 functions should not be permitted in an MLS system when certain MLS options have been activated. The following restrictions apply when MLS is active on an CA Top Secret system:
This checklist describes the software configuration requirements when MLS is active on an CA Top Secret system.
|
Requirement |
Complete |
|---|---|
|
Control the use of JES3 operator commands |
□ |
|
Protect JES3 Spool Data Sets |
□ |
|
Define acid for JES3 started task |
□ |
|
Assign security label SYSMULTI to the JES3 started task ID |
□ |
|
Define access rules for JES3 started task |
□ |
|
Control Job Input |
□ |
|
Configure Network Job Entry (NJE) and Remote Job Processing (RJP) |
□ |
The security administrator must be able to audit all JES3 commands in an MLS system. It is also necessary to control who can issue commands, since it is possible to issue commands not only from an operator console, but also from batch JCL. In either case, access is validated based on the acid associated with the job. To control JES3 commands and provide an audit trail for all JES3 commands, do the following:
JES3 commands have resource names that follow the example below:
jesname.command[.qualifier]
The name of the JES3 system requesting the command validation
The name of the JES3 command
The type of object the command specifies, such as JOB or SYS.
See the IBM z/OS JES3 Initialization and Tuning Guide to determine the resource name of the JES3 command. It provides a list of JES3 commands, their resource names, and the SAF access level required to issue the command.
The $C'jobname' command has the following resource name:
jesx.CANCEL.JOB.
A user requires UPDATE access to issue the command. Here are some sample rules to protect JES3 commands:
The following permit allows system operator OPER1 to issue any JES3 commands, but CA Top Secret creates a log record for each JES3 command issued.
TSS PER(oper1) OPERCMDS(*all*)
ACTION(audit)
You could create more specific entries in the permit to establish a finer control over the operators issuing JES3 commands.
The following rule lets OPER1 cancel jobs
TSS PER(oper1) OPERCMDS(JES.CANCEL)
JES3 maintains data sets in the JES3 spool. Some of these data sets are JES3 system and user data sets. Others contain SYSIN and SYSOUT data for jobs in the system. This section describes how to protect the following types of JES3 spool data sets:
In order for any users to read or update classified JES3 spool data sets in an MLS system, their security labels must dominate the security labels of the spool data sets they are trying to access.
MLS protection mechanisms for JES3 SYSIN (for the job's input) and SYSOUT (for the job's output) data sets allow access to them only by the user who created the data sets. The user can also allow other users access.
When the MLS option to protect write-down is active, the system assigns the SYSIN and SYSOUT data sets the same label as the job. The subject that submits the job can access these data sets if their security label dominates the job's security label.
While a job executes, JES3 creates SYSIN and SYSOUT data sets using the following naming conventions:
nodeid.userid.jobname.jobid.dsnumber.name
The name of the node where the data sets reside. In an MLS system, this is always the local node. The ID of the local node appears in the job log of each job.
Note: The variable, nodeid, is not part of the data set name. Rather, it is added to the front of the data set name for the SAF call.
The ID of the user associated with the job. This is the acid specified in the USER= keyword on the JCL JOB statement or the acid of the user who submits the job.
The name of the job as it appears in the NAME field of the JOB statement.
The job number JES3 assigns to the job. JES3 displays the job ID in messages sent to the submitter and in the job log of every job.
The unique data set number assigned by JES3 to the spool data set. D is the first character of the number.
The name of the data set as it is specified in the DSN= parameter of the DD statement in the job. The name cannot be JESYSMSG, JESJCLIN, JESJCL, or JESMSGLG. If the DSN= parameter is not specified in the DD statement that creates the spool data set in the JCL, JES3 uses a question mark (?) for the name.
The SYSLOG data set contains a record of a systems' daily activities. To prevent unauthorized access to SYSLOG in an MLS system, the SYSLOG data set should be assigned the security label, SYSHIGH. This means that only trusted programs and processes that are part of or defined to the system can access the SYSLOG.
To allow an operator DAC access to the SYSLOG data set, a security administrator must create a resource rule for the JESSPOOL resource class and a resource name such as:
home.+MASTER+.-.-.-.SYSLOG.
Note: The variable, home, is not part of the data set name. Rather, it is added to the front of the data set name for the SAF call.
The JES3 spool space data sets hold JES3 sysin and sysout files for jobs that are waiting for execution or printing. The JES3 checkpoint data sets provide an index into the spool space, and allow communication between JES3 address spaces running on different members of a multi-access spool complex. JES3 issues SAF calls to protect individual sysin and sysout data sets. To prevent other jobs from circumventing JES3 security, only JES3 may be given access to the spool space and checkpoint data sets. Since the JES3 acid does not have any special attributes, JES3 must be explicitly granted access to these data sets.
You should also assign a default security label of SYSMULTI to the JES3 started task. This will allow ACEEs with different security labels to be anchored in TCBs in the JES3 address space.
A security administrator can create resource rules to control which users can submit or cancel specific jobs and which input devices users can submit jobs from.
A site can optionally control which users can submit or cancel specific jobs, such as those that offload spool data sets. To do this the security administrator must activate the JESJOBS resource class and write resource rules for the SUBMIT and CANCEL resources.
If you want to successfully use NJE and RJP in an CA Top Secret MLS system, configure them as follows:
|
Copyright © 2010 CA Technologies.
All rights reserved.
|
|