Started Task ACID Accesses

Document ID : KB000048290
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

What authority or access should be given to a started task ACID to allow the ACID access to the resources it needs in CA Top Secret?

Solution:

First, the started task ACID will need the STC facility.


 	TSS ADD(acid) FAC(STC) 

The ACID will also need access to all resources accessed at startup. These include things like datasets in a STEPLIB.

If unsure of all the resources accessed at startup for a new started task, permit MODE(WARN) to the started task ACID temporarily so any accesses will log violations but will not be denied. After running this way for a little while, you can run TSSUTIL with the following to see the violations for this ACID.


 	REPORT EVENT(VIOL) ACID(xxx) 

where 'xxx' is the started task acid

Once you issue the corresponding permits to correct the violations, revoke the permit for MODE(WARN) on the started task ACID .

Another note for started task acids:

We recommend that all started task (STC) ACIDs be given a password and OPTIONS(4) be set in the CA Top Secret parameter file. OPTIONS(4) will eliminate the prompt for a password when the STC starts, but if someone tries to sign on with the STC ACID , he will need to know the password.

CA Top Secret has bypass attributes such as NODSNCHK, NOSUBCHK, NORESCHK, etc that can be added to the started task ACID to bypass security for things like datasets (NODSNCHK), acid cross authorization checks (NOSUBCHK), resources other than datasets and volumes (NORESCHK), volumes (NOVOLCHK). If there are a lot of resources that need to be permitted to the started task ACID , the bypass attribute(s) could be added instead of permitting all the resources. Accesses allowed via a bypass attribute cause an OK+B record to be logged to the audit file, so logging of these accesses can be tracked.

Because the password requirement has been eliminated from the job card, even in cases where the USER= parameter is coded, the submit check must be repeated within the JES address space. At this time, the submitting ACID will be identified by JES. This means that, for jobs submitted from a multi-user address space such as CICS, both the submitting ACID and the region ACID must be cross-authorized to the execution acid for the job being submitted. The best way to ensure that this additional authorization is available is to put NOSUBCHK on the region ACID.

Alternatively, the region ACID may be cross authorized to the individual execution ACIDs. This requirement applies to both JES2 3.1.3 or above, and JES3 3.1.3 or above, whether or not JES(VERIFY) is in effect.

So if the started task ACID is for a multi user address space where jobs are submitted, the started task acid will need NOSUBCHK added to it or will need to be permitted to all acids that jobs submitted from this address space will run under. This is most common for CICS region acids.