Implementing Ownable Resource Security › Providing a Security Environment for VM Batch Subsystems

Providing a Security Environment for VM Batch Subsystems

Assume, for example, that you wish to correct a security exposure between a batch controller machine named “BATCHC” and three batch worker machines “BATCH01,” “BATCH02,” and “BATCH03.”

To permit the controller use of the diagnose required to invoke the surrogate function, enter:

TSS ADDTO(dept) DIAG(D4)
TSS PER(BATCHC) DIAG(D4)

To permit the controller to surrogate the batch worker machines, enter one of the following:

TSS ADDTO(dept) VMMACH(BATCH0)
TSS PER(BATCHC) VMMACH(BATCH0) ACC(SUROGATE)

To permit the controller access to the job submitters’ ACIDs so that they can be used in surrogacy either by explicitly permitting the controller to the ACID of each potential submitter or through the NOSUBCHK attribute, enter one of the following:

TSS PER(BATCHC) ACID(submitter, submitter, etc.)
TSS ADDTO(BATCHC) NOSUBCHK

If your batch jobs typically link to the submitter’s minidisks, a security check will be performed when the batch worker attempts the link. The following commands will provide this permission:

TSS ADD(msca acid) VMMDISK(%.)
TSS PER(ALL) VMMDISK(%.) ACC(READ)

This will allow any ACID READ access to its own virtual machine’s minidisks.

Note: The CMS batch facility included in the VM base product does not support external security. It is possible, however, for an installation to implement surrogacy for CMS batch by defining a trusted “front-end” virtual machine. This machine would receive a submitted job, validate the submit authority using the CA Top Secret Application Interface, surrogate the CMS batch machine, and then transfer the job to it. Care must be taken in setting up this type of application to ensure proper serialization of work.