Implementing Data Set Security
Data Set Security
Data set securityrefers to the protection of files that are accessed and maintained by
CA Endevor SCM. The alternate ID feature lets you restrict access to specified data sets by the user ID specified in the customer default table. This ID automatically determines which data sets are controlled by
CA Endevor SCM. This practice lets the product perform updates only on the set of libraries you specify.
Add the names of non-
CA Endevor SCMprograms to the Authorized Program Table (C1GTAPGM), if these programs are invoked within a processor and need to run APF-authorized. For more information, see Logical and Physical Inventory Structure
Alternate ID Support
Some versions of program pathing do not support the ability to recognize top-level programs through conventional means. A special interface has been developed to be used with CA ACF2, CA Top Secret, and RACF to enable you to perform data set security using alternate ID support. This interface allows manipulation of data sets and their contents through
CA Endevor SCM, using an alternate user ID.
This method of data set security ensures that updates to controlled data sets are performed only through
CA Endevor SCM. External access to these files by the product users is prohibited. For example, if an element is changed outside of the product, then the the product footprint is compromised.
The alternate ID support feature lets a site protect the
CA Endevor SCMdata sets (that is, base, delta, listing, and source output libraries, and Master Control Files, the package data set, and processor output libraries) from direct update by users.
When using alternate ID support, a separate user ID is defined to
CA Endevor SCM. This separate or alternate ID is granted update authority for the
CA Endevor SCMlibraries. When
CA Endevor SCMneeds to update these libraries, the system use the authorization assigned to the alternate ID.
By defining an alternate ID and assigning it specific update authorization, you can prevent a user from inadvertently updating particular libraries.
Alternate ID support for USS files and directories is subject to certain limitations. Limited alternate ID support for UNIX files and directories can be enabled by turning on the ENABLE_ALTID_USS_SECURITY option in the Options table. For more information, see Alternate ID Support for UNIX Files.
We recommend using alternate ID support for data set security.
The Alternate ID
When defining your environment, you can optionally specify a RACF ID, known as the
CA Endevor SCMAlternate ID, in your C1DELFTS to be used when accessing
CA Endevor SCMcontrolled resources such as the MCF, package data sets, processor data sets, or the element catalog. If an Alternate ID has been specified it is used instead of the user ID when accessing these resources.
If the OPEN SVC screen detects that the OPEN was issued from
CA Endevor SCMI/O modules, and the target file appears to be an
CA Endevor SCMfile, then the TCBSENV field is swapped to the Alternate ID, causing the task to run under the security context of the Alternate ID. When the OPEN completes, the field is swapped back to its earlier value. This logic is bypassed if ALTID=N is coded.
The External Security Interface (ESI) never switches to the
CA Endevor SCMAlternate ID. ESI is used to determine whether a user has the right to perform certain
CA Endevor SCMactions. It performs this check by issuing an RACROUTE REQUEST=AUTH call to validate a user's access.
What the Alternate ID Controls
When activated, the alternate user ID is used when any of the following data set categories are accessed. An access level of UPDATE is required for these data sets. However, for the Master Control File, Element Catalog File, Element Index File, Package Control File, and ELIB VSAM data sets, access level of CONTROL is required.
- All data sets contained in generate, move, or delete processors*
- ACMQ root and XREF data sets
- Base/delta libraries*
- Batch request data sets
- CCID validation data set
- Element Catalog File
- Element Index File
- ISPF (foreground) data sets
- Master Control File
- Package Control File
- Package ship staging data sets
- Processor load libraries
- Source input libraries (for example, include libraries)*
- Source output libraries (for example, load libraries)*
*If these are USS files, alternate ID support is not available for delta libraries. Support is limited for USS files that are accessed in processors and user exits. For more information, see Alternate ID Support for UNIX Files.
What the Alternate ID Does Not Control
Several categories of data sets can only be accessed by the originating TSO user ID, including
- ADD/UPDATE FROM:data set
- Any data sets controlled by the CA Common Services component CA L Serv
- ARCHIVE/TRANSFER TO:data set
- Batch request data sets
- COPY FROM:data set
- Foreground ISPF Data Sets (for example, uid.C1TEMPRnMSGS, uidC1TEMPncntl, uid.C1#NTMPL.LIST)
- JES2 files SYSIN and SYSOUT data sets
- LIST FROM:data set
- PRINT TO:data set
- RESTORE FROM:data set
- RETRIEVE TO:data set
- TRANSFER FROM:data set
The alternate ID is not swapped on the creation or deletion of a data set or PDS in a processor. The user TSO user ID must have authority to create or delete the data set or PDS.
How to Activate the Alternate ID for Data Set Protection
To implement the Alternate ID support feature, specify the alternate user ID in the Defaults table, build profiles to protect the libraries, and grant update authority to the Alternate ID for those libraries as indicated in the following steps. An additional step is required to enable Alternate ID protection for USS files and directories. Alternate ID support for USS files and directories is subject to certain limitations. For more information, see USS Supported Files and the Alternate ID.
Follow these steps:
- Update the TYPE=MAIN macro in theCA Endevor SCMDefaults table (C1DEFLTS) to include (or update) the RACFUID parameter. Set the value for theuseridvariable to the The RACF, CA ACF2, or CA Top Secret user ID that is to be used for data set authorization checking.
- RACFUID =userid,Indicates the user ID required for Alternate ID support.
- Assemble and link C1DEFLTS into the authorized load library and issue an LLA refresh for the library.
- Use your site security system to build profiles to protect the libraries, and grant update authority to the Alternate ID for those libraries.
- To perform periodic maintenance against the various files underCA Endevor SCMcontrol such as PDS compress and VSAM Repro, grant your administrator the same permissions as the RACFUID. Also, RACFUID needs READ access to the CONLIB. Some types of file maintenance, such as full file restore, may require a higher level of authority than that granted to the RACFUID. Be sure to allow someone the appropriate authority to address this event.
- If you want to enable Alternate ID protection for USS files and directories, turn on the following option in the Options table:
- ENABLE_ALTID_USS_SECURITY=(ON,nn)Indicates whether Alternate ID support is enabled for UNIX USS files.
- ONThe UNIX files that are managed byCA Endevor SCMis owned by the Alternate ID. The file owner (alternate ID) will have read, write, and execute access to new base and source output files. This support is limited to UNIX base libraries, include libraries, and source output files that are defined as UNIX directories. Some support is also provided for UNIX files that are accessed in processors and user exits.
- OFFThe UNIX files that are managed byCA Endevor SCMwillnotbe owned by the Alternate ID. Default.
- nnThe UNIX file permission bits (rwx) for the owning group and other users, given to new and base source output files. The default is 55, meaning that the owning group and others have read and execute access.
Example: C1DEFLTS Parameter RACFUID
This example shows how to activate the Alternate ID for data set protection for your site.
C1DEFLTS TYPE=MAIN, X ACCSTBL=, ACCESS SECURITY TABLE NAME X ACMROOT=, ACM INDEX ROOT DATA SET NAME X ACMXREF=, ACM INDEX XREF DATA SET NAME X . . .RACFUID=userid,Alternate ID USERIDX
Enable the Alternate ID for UNIX Files
To use alternate ID security for UNIX files, the administrator must enable this feature:
- Specify an alternate ID value in the RACFUID field of C1DEFLTS. For more information, see How to Activate the Alternate ID for Data Set Protection.
- Set the ENABLE_ALTID_USS_SECURITY option to ON in the Optional Features table. The default for this option is OFF. For more information, see How to Activate the Alternate ID for Data Set Protection.
- Enhance the security definition of the alternate ID to include UNIX security. Consult with your site security administrator and see the appropriate documentation for the External Security Manager (CA ACF2, CA Top Secret, or RACF).
- If you have existing UNIX files and directories that you want to protect, ensure that the permissions are set as shown:
Owner (alternate ID)
Follow these steps:
- Use the ‘chown’ (change owner) UNIX command to change the owner to the alternate ID and the group ID to a group that includes the alternate ID. (A superuse must issue the ‘chown’ command.)
- Use the ‘chmod’ (change permissions) command to change the permissions of directories and files to those shown in the previous table.
- To restrict read access to the directories to the alternate ID, omit the read permission for group and other.
How the Alternate ID Works with Processors
If the alternate ID is activated for data set protection at your site, you can specify whether the alternate ID is used in processors. Processor security is controlled by the EXEC statement ALTID parameter. Code one of the following options.
The default. Swaps the security context to that of the alternate ID during the processor step. The data sets specified in a processor step are allocated under the user ID. When the processor program is run, it runs under the alternate ID, so that access to the data sets (except for JES2 files) occurs under the alternate ID.
- ALTID=NIf you do not want the processor step to run under the security context of the alternate ID, then code ALTID=N on the exec statement for that step. Security context remains that of the user ID during the processor step. If your processor step includes a file whose output destination is the internal reader, the job step runs under the user ID.
Security for internal reader jobs is affected by the Optional Features Table (ENCOPTBL) option INTRDR_ALTID and processor ALTID settings as shown in the following table.
Y or blank (default)
Any processor step that includes an INTRDR DD card is run under the user ID. No swapping to the altid for data access occurs. The job that is submitted to the internal reader runs under the user ID.
Processor step runs under the user ID, therefore internal reader job is submitted under user ID.
Y or blank (default)
Processor step runs under the altid, therefore internal reader job is submitted under altid.
Processor step runs under the user ID, therefore internal reader job runs under the user ID. Note: ALTID=N overrides INTRDR_ALTID=ON.
If the job is being submitted by a REXX exec, then the LGNT$$$I/O logic must be used in the REXX, regardless of whether the internal reader is allocated in the REXX itself or with an INTRDR DD statement in the processor. For more information, see Using the Alternate ID with REXX and the Internal Reader.
JES2 files are always opened under the user ID, regardless of the setting of ALTID in the processor step.
How the Alternate ID Works for User Exits
If the alternate ID is activated for data set protection at your site, you can specify whether the alternate ID is used in user and package exits. Security for user and package exits is controlled by the user exit table C1UEXITS parameter USE_ALTID=. You can specify one of the following options:
The default. Swaps to the alternate ID for data set security validation at OPEN time. Swaps security back to user ID when the data set open completes. Therefore, access to data sets is under the alternate ID, but the security context for all other processing is the user ID.
- USE_ALTID=+The security context is that of the alternate ID during the exit. Therefore, access to data sets occurs under the alternate ID as does all other processing. Use this option if you want to submit your internal reader jobs under the alternate ID.
- USE_ALTID=NThe user exit runs completely under the security context of the user ID. The security context is never swapped to that of the alternate ID. All data set access and processing occurs under the user ID.
Example: User Exit Security Checks Using Alternate ID for Data Set Access Only
This example shows how to code the user exit table to have data set access occur under the alternate ID, but all other processing occurs under the user ID, during exit 1
Example: User Exit Security Checks Using Alternate ID for All Processing
This example shows how to code the user exit table to have data set access and all other processing occur under that alternate ID, during exit 2.
Example: User Exit Security Checks Using User ID Only
This example shows how to code the user exit table to have data set access and all other processing occur under that user ID, during exit 3.
JES2 files are opened under the user ID, regardless of the setting of the USE_ALTID in the user exit table.
Alternate ID and Package Output Shipping
During package output shipping, a job is submitted to perform the actual shipping process. This job can be submitted by the alternate ID instead of the user’s ID. To have the job submitted by the alternate ID, the PACKAGE_SHIP_WITH_ALTID=ON setting must be enabled in the optional features table (ENCOPTBL). This option causes the JCL to be copied to an MVS internal reader under the security scope of the alternate ID.
The package ship job JCL is generated by ISPF services into a data set named for example userid.sysid.SPFTEMPx.CNTL, which is owned by the user. Therefore, when using PACKAGE_SHIP_WITH_ALTID=ON, the alternate ID must have Read access to that data set in order to copy it to the internal reader.
How Security Checking Works with JES2 Data Sets
JES2 files are always opened under the user ID, regardless of the setting of ALTID in the processor step, or USE_ALTID in the user exit table. When a JES2 file opens, the security context reverts to the user ID. When the open completes, the open screen resets the security context back to the Alternate ID. The JES2 data sets are accessed under the user ID to avoid the situation where an abend occurs and the processor dump information is written under the Alternate ID. This situation would cause security issues because the SYSUDUMP is most likely allocated in the main job (not the processor) and is therefore might not be accessible to the Alternate ID.
Using LGNT$$$I, LGNT$$$O Logic
When LGNT$$$I, LGNT$$$O logic is coded in a CLIST or REXX exec defined in a processor, the swap to the Alternate ID is done for the entire address space. This logic can be used to allow DB2 BINDS to run under the Alternate ID or to allow a job that is written to the INTRDR from the CLIST or REXX exec to run under the Alternate ID.
- When a LGNT$$$I file is opened during processor step execution, then the security context for the job step becomes that of the Alternate ID. The ASXBSENV and ASXBUSER values are set to those of the Alternate ID.
- When a LGNT$$$O file is opened during processor step execution, then the security context for the job step is restored to that of the user ID. The ASXBSENV and ASXBUSER values are set to those of the user ID. To swap the ASXBUSER and ASXBSENV fields, opening LGNT$$$I and LGNT$$$O must occur in the same processor step as the DSN subcommand if a DB2 BIND is being executed, or as the write to the INTRDR if a job is being submitted to the internal reader. When the processor step ends, to account for the possibility that the LGNT$$$O logic was omitted, these values are always reset to that of the user ID. If the processor step abends, the values are reset back to the user ID.
If ALTID=N is coded on the processor EXEC statement, LGNT$$$I and LGNT$$$$O processing is bypassed and no security context swapping occurs.
To swap the ASXBUSER and ASXBSENV fields, opening LGNT$$$I and LGNT$$$O must occur in the same processor step as the DSN subcommand.
Using the Alternate ID with DB2
Implementing the Alternate ID for DB2 allows binds of DB2 PLANS to occur under control of the Alternate ID, rather than the user ID when the bind occurs during processor execution.
DB2 security may be under RACF control. If it is not, then DB2 uses the ASXUSER value to determine the security context. If RACF is being used, the value of the ASXBSENV field is used. The LGN$$$I/LGNT$$$0 mechanism updates both these fields.
- ASXBUSERThe primary DB2 authorization ID and is a seven character field. The Alternate ID must also be seven characters or less.
- ASXBSENVThe address of the ACEE control block that controls security of the address space level.
ASXBUSER is not used by RACF to determine the user ID authority for security groups. The Alternate ID must be assigned the DB2 authority necessary to issue the bind. Attempts to assign the Alternate ID to a group that has the necessary authority fails with DB2 authorization errors.
After opening file LGNT$$$I, both the AXSBUSER and ASXBSENV fields are updated to Alternate ID values. After opening LGNT$$$O, these values are reset to their original values. Opening these files triggers the Alternate ID swap. To swap the ASXBUSER and ASXBSENV fields, opening LGNT$$$I and LGNT$$$O must occur in the same processor step as the DSN subcommand.
Example: CLIST invoked by BC1PTMP0 to implement the DB2 Alternate ID
WRITE ** SWAP ID TO ALTERNATE ALLOC FILE (LGNT$$$I) DUMMY OPENFILE LGNT$$$I CLOSFILE LGNT$$$I FREE FILE(LGNT$$$I) WRITE ** BIND PLAN USING ALTERNATE ID DSN SYSTEM(DSN6) BIND PLAN(SQLASM01) MEM(SQLASM01) VAL(RUN) ACT(REP) ISO(RR) END WRITE ** OPEN AND SWAP ID BACK TO USERS ORIGINAL ID ALLOC FILE(LGNT$$$O) DUMMY OPENFILE LGNT$$$O CLOSFILE LGNT$$$O FREE FILE(LGNT$$$O)
Using the Alternate ID with REXX and the Internal Reader
In a processor, if you are submitting jobs to an internal reader from a REXX exec, to swap to the alternate ID, code the LGNT$$$I/LGNT$$$O logic into your REXX. This requirement applies whether the internal reader is allocated in the REXX exec or in an INTRDR DD statement in the processor.
Example: REXX, the Internal Reader, and the Alternate ID
This example shows how to code a REXX to swap to the Alternate ID for the internal reader.
/* REXX */ "ALLOC F(JOBOUT1) SYSOUT(A) WRITER(INTRDR)" queue "SWAP TO ALTERNATE ID" Queue "ALLOC FILE(LGNT$$$I) DUMMY" "execio "queued()" diskw LGNT$$$I (finis" "FREE FILE(LGNT$$$I)" queue "//&PMFKEYA JOB (108200000),'KEIR'," queue "// CLASS=A,MSGCLASS=X," queue "// NOTIFY=&PMFKEY" queue "//ENDEVOR EXEC PGM=IEBGENER" queue "//SYSPRINT DD DUMMY" queue "//SYSIN DD DUMMY" queue "//SYSUT1 DD *" queue "TEST" queue "//SYSUT2 DD SYSOUT=*" Queue "execio "queued()" diskw jobout1 (finis" queue "SWAP BACK TO USERID" Queue "ALLOC FILE(LGNT$$$O) DUMMY" "execio "queued()" diskw LGNT$$$O (finis" "FREE FILE(LGNT$$$O)" "FREE FILE(JOBOUT1)" PUSH END
USS Supported Files and the Alternate ID
When using a USS base library,
CA Endevor SCMsource management accesses the library using the alternate ID.
CA Endevor SCMuses the alternate ID when it accesses a USS source output library in the product reserved processors BASICGEN and BASICDEL.
The security context of a processor step is determined by the following factors:
- ALTID keywordThe security context that is used for USS file access in processor steps is determined by the ALTID keyword. Processors can run under the credentials of the user or under the Alternate ID, so that USS outputs (created, copied, compiled, and so on) have the Alternate ID as the owner or group owner. For more information about Alternate ID support, see How to Activate the Alternate ID for Data Set Protection.
- PATHOPTS=(OCREAT)Any USS data sets created in processor steps using PATHOPTS=(OCREAT) are created using the security context of the user ID, prior to the invocation of the processor program. When used in the processor step, these data sets are opened using the security context of the processor step.
- EXEC PGM=BPXBATCHThe security context of a processor step executing the IBM USS utility program BPXBATCH depends on the following factors:
- Whether BPXBATCH runs a shell script (PARM=’SH’) or directly executes an executable file (PARM=’PGM’). We recommend BPXBATCH be invoked directly as processor step.
- The settings of the Environment variables _BPX_BATCH_SPAWN and _BPX_SHAREAS.
- BPXBATSL, BPXBATA2 and BPXBATA8These programs run under the context of the user ID, because they process requests in the same manner as the last row in the prior table (_BPX_BATCH_SPAWN=YES, and _BPX_SHAREAS=YES).
- BPXBATCH in an IKJEFT01 processor stepWe do not recommend the use of BPXBATCH in an IKJEFT01 step, because the results can be unpredictable.Whether BPXBATCH invoked by a CLIST or REXX in a processor step executing IKJEFT01 executes under the context of the alternate ID depends on the following twoadditionalfactors:
- Whether a LGNT$$$I swap was performed prior to the invocation of BPXBATCH.
- Whether a prior USS service call was made in the job step prior to the BPXPBATCH call. For example, the prior USS service call could occur when a USS Base or Source Output Library was used during theCA Endevor SCMjob step, or when a shell script was executed in this or any priorCA Endevor SCMaction.
LGNT$$$I swap performed
Prior USS Service call made
To activate alternate ID support for data set protection, the administrator must perform certain steps. An additional step is required to activate alternate ID support for UNIX USS files. For more information, see How to Activate the Alternate ID for Data Set Protection.
CA Endevor SCMsupports access to UNIX files and directories in certain situations. For more information, see Long-Name Files and USS Supported Files
Alternate ID Processing at Initialization
If alternate ID support is enabled, then in addition to changing the file permissions set for UNIX files that are managed by
CA Endevor SCM, enablement of this option causes the product to do the following processing at initialization.
- Attempt to establish the alternate ID UNIX security context by issuing an initUSP to acquire the USP (UNIX Security Packet) for the alternate ID. (If the alternate ID UNIX security context has already been established, this step is bypassed.)
- Dub the address space by issuing a getUID call, if the address space has not already been dubbed. (The getUID call simply returns the UID associated with the process. However, because it is a UNIX callable service, it forces the address space to be dubbed if it is not already dubbed.)
If any of the these items fail, an error message is
notissued until the first attempt to perform UNIX I/O is made. This practice is done to avoid issuing these messages when no UNIX activity is taking place.
Program pathing currently is available through both the CA ACF2 for z/OS and CA Top Secret for z/OS security packages. Data set security is implemented through a special Alternate ID interface, using an assigned RACF user ID and optional password for
CA Endevor SCM.
When using CA ACF2 or CA Top Secret with program pathing, define the top-level programs that recognize
CA Endevor SCMas the program in control for both foreground and batch processing. Resource rules
mustbe written for the top-level programs. Depending on-site requirements, resource rules may be written for other
CA Endevor SCMprograms. A list of the produc's top-level programs requiring resource rules follows:
This list can change. Your site security needs can require resource rules for other
CA Endevor SCMprograms, and you can simply add these programs to the list. If you use CA Top Secret for z/OS, you can simplify the coding process by using the PRIVPGM option when writing a resource rule.
Data set security for CA ACF2 for z/OS and CA Top Secret for z/OS requires optional APARS and USERMODS from the appropriate CA Technical Support group.
The following diagram illustrates that
CA Endevor SCMruns as an ISPF dialog under program ISPTASK.
As previously illustrated, ISPTASK must be addressed from a global point across the entire TSO environment, before attempting program pathing for
CA Endevor SCMor any other ISPF dialog package.