Implement Member-Level Protection
acf provides the ability to protect partitioned data sets (PDS) at the member level. In the past, access to PDS data could be allowed or denied only at the data set level; that is, a user with read access to a PDS could read all members of a PDS, and a user with write access could update all members of a PDS.
CA ACF2provides the ability to protect partitioned data sets (PDS) at the member level. In the past, access to PDS data could be allowed or denied only at the data set level; that is, a user with read access to a PDS could read all members of a PDS, and a user with write access could update all members of a PDS.
CA ACF2member-level protection, the security administrator can restrict which members of a PDS a user can access. Therefore, a user with read access to a member-level protected PDS library is only allowed to see those members for which PDS resource rules have been defined. A user with write access to a member-level protected library is restricted to which members can be updated and also which members can be created and deleted.
To report on PDS member-level access requests, you can produce the ACFRPTRV resource event log. ACFRPTRV shows the results of resource validation requests (including any PDS member-level violations).
The first step in implementing member-level protection is determining which PDS libraries require member-level protection. We do not recommend protecting individual user PDS libraries. Select the system and application libraries for which member-level protection is desired.
These libraries are identified to
CA ACF2through the use of the GSO PDS record. The PDS record also identifies the resource rules against which member-level protection is performed through specification of the resource rule type code. These rules must be globally resident.
The resource rule key is the member accessed. There is also a special resource name <DIR>, which represents a direct access to the PDS directory. Most applications do not access the PDS directory directly. However, a PDS can be destroyed if a user inadvertently opens the PDS as a sequential data set. Use of a <DIR> resource rule for a member-level protected library can prevent that occurrence.
The resource rule SERVICE keyword can be used to identify the type of access being made to the PDS member as follows:
- READThe member is being read.
- UPDATEThe member is being updated, created, or deleted.
The following steps explain how to implement PDS member-level protection:
- Determine the library that requires member-level protection.
- Determine the resource rule type code to use for this validation.
- Write resource rules for the members in that library.
- Ensure that the resource rules are made globally resident.
- Define the library, volume, and resource type in the GSO PDS record.
- REFRESH the PDS record to activate member-level protection for that library.
The following example shows protection of SYS2.PROCLIB so that users can update only those members that begin with a dollar sign($) but are allowed to read all members.
- SYS2.PROCLIB is the library to be protected.
- Resource type code PDS is used to write rules for this library.
- Write the following rules:SET R(PDS) $KEY($*******) T(PDS) UID(-) ALLOW $KEY(********) T(PDS) UID(sysprog) ALLOW UID(-) SERVICE(READ) ALLOW
- Add the resource type code to INFODIR.SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RPDS)
- Perform a console REFRESH and REBUILD to make the rules resident.F ACF2,REFRESH(INFODIR) F ACF2,REBUILD(PDS)
- Define the library and resource type in the GSO PDS record. Since VOLUME is not specified, SYS2.PROCLIB is protected regardless of where it resides.SET CONTROL(GSO) INSERT PDS.proc2 LIBRARY(sys2.proclib) RSRCTYPE(PDS)
- Perform a console REFRESH to activate the protection.F ACF2,REFRESH(PDS)
Using ACFNRULE in Batch
The following is an example using ACFNRULE in batch:
//ADDRULE EXEC PGM=ACFNRULE,REGION=128K, // PARM='KEY(SYS1),DEL(PARMLIB),ADD(PARMLIB UID(ABC), // LIB(''ACF2.PROD'') READ(A))' //SYSPRINT DD SYSOUT=*
To do multiple adds and updates in batch:
/ADDRULE EXEC PGM=ACFNRULE,REGION=128K, // PARM='KEY(SYS1),ADD(PROCLIB UID(ABC)),ADD(PARMLIB UID(ABC))' //SYSPRINT DD SYSOUT=*
The following is an example of the ACFNRULE utility in batch, with output directed to a dataset:
//ADDRULE EXEC PGM=ACFNRULE,REGION=128K, // PARM='KEY(SYS1),DEL(PARMLIB)' //SYSPRINT DD DSN=RULE.OUTPUT,DISP=(MOD,CATLG), // UNIT=SYSDA,SPACE=(TRK,(1,1)).
The following is an example of the ACFNRULE utility in batch, with input from SYSIN:
//ADDRULE EXEC PGM=ACFNRULE,REGION=128K //SYSPRINT DD SYSOUT=A //SYSIN DD DSN=NRULE.INPUT,DISP=SHR
//ADDRULE EXEC PGM=ACFNRULE,REGION=128K //SYSPRINT DD SYSOUT=A //SYSIN DD * KEY(RESRULE) TYPE(CAI) DEL(- L3NG.VERY.LONG.RESOURCE.NAME.FOR.TESTING.EXTENDED.RESOURCE.RULE.NAMES.L4- NG.VERY.LONG.RESOURCE.NAME.FOR.TEST UID(USERT99) ALLOW) ADD(- L09G.VERY.LONG.RESOURCE.NAME.FOR.TESTING.EXTENDED.RESOURCE.RULE.NAMES.- L2NG.VERY.LONG.RESOURCE.NAME.FOR.TESTING.EXTENDED.RESOURCE.RULE.NAMES.L- NG.VERY.LONG.RESOURCE.NAME.FOR.TEST UID(USERS99) ALLOW)
To do multiple adds and updates in batch with input from SYSIN:
//SYSIN DD * KEY(RULE) ADD(PROCLIB UID(ABC) R(A)) ADD(TESTLIB UID(DBS) R(A))
You can define libraries to use the same resource type code if their protection requirements are the same. In this example, the same resource rules protect both SYS1.PARMLIB and SYS2.PARMLIB while resource rules with type code PDJ protect the production JCL library:
INSERT PDS.parm1 LIB(sys1.parmlib) RSRC(PDS) INSERT PDS.parm2 LIB(sys2.parmlib) RSRC(PDS) INSERT PDS.jcl LIB(prod.jcllib) RSRC(PDJ)
You can use the VOLUME keyword to restrict protection to a specific library. This example protects the production parmlib on SYSRES but does not protect any other SYS1.PARMLIB data sets that reside on other volumes:
INSERT PDS.parm1 LIB(sys1.parmlib) VOL(sysres) RSRC(PDS)
Use of the special resource name PDSALLOW lets you specify a library that is not to be protected. In this example, the parmlib on volume TSTRES is not to be protected, but all other SYS1.PARMLIB libraries are to be protected:
INSERT PDS.parm1 LIB(sys1.parmlib) VOL(tstres) RSRC(PDSALLOW) INSERT PDS.parm2 LIB(sys1.parmlib) RSRC(PDS)
You might encounter situations in which you want to bypass member-level protection for a PDS that is normally protected. When a protected library is accessed, a data set validation call is performed with a data set name of CAPDSSEC.BYPASS.rsrctype for write access. The
rsrctypevalue is from the GSO PDS record that describes the data set or data sets that are protected. If access is allowed to this data set resource, PDS member-level validation is bypassed.
The following example shows that users in production control do not need member-level protection rules for data sets controlled by the PDJ resource type. Also, system programmers can access any member-level protected data set when using the IEBCOPY program.
SET RULE $KEY(CAPDSSEC) BYPASS.PDJ UID(prodcntl) W(A) BYPASS.- UID(sysprog) PGM(IEBCOPY) LIB('SYS1.LINKLIB') W(A)
If GSO OPTS MODE setting specifies RULE, and anything other than ABORT is specified for the norule condition, member-level protection is bypassed for all users. If using RULE mode, ensure that a CAPDSSEC access rule with $MODE(ABORT) is created.
The compression of a partitioned data set under member-level protection raises a special concern. Normally, the user performing the compress is required to have READ access to all members of the data set and UPDATE access to the special resource <DIR>.
A sample rule to secure the <DIR> resource is as follows:
SET RESOURCE(PDS) $KEY(<DIR>) TYPE(PDS) UID(sysprog) SERVICE(UPDATE) ALLOW
If this access cannot be given, and the user does not have any overriding privileges, such as NON-CNCL or READALL, use of the BYPASS rule, described above, can allow access. In addition to restricting the user to the IEBCOPY program, other controls, such as SHIFT, SOURCE, and UNTIL, can be used to control this type of access.
Using ACFNRULE in TSO
The following is an example using the ACFNRULE in TSO:
ACFNRULE KEY(SYS1) DEL(PARMLIB) ADD(PARMLIB UID(ABC) LIB(''ACF2.PROD'') R(A))
To do multiple adds and updates in TSO
ACFNRULE KEY(KENTST) ADD(TEST UID(XYZ) R(A)),ADD(DFG UID(TST) R(A)) or ACFNRULE KEY(KENTST) DEL(TEST UID(ABC)),DEL(PARMLIB)
Write CLISTs in ACFNRULE
ACFNRULE might become more useful if various CLISTs are written to aid in common functions. For example, the following CLIST adds a rule enabling consultants to read a data set for three days:
PROC 1 DSN FOR(3) ACFNRULE KEY(&SYSUID.) ADD(&DSN. UID(**C) READ(A) FOR(&FOR.)) NOVERIFY
Notes and Restrictions
PDS member-level protection requires that the CA Common Services must be active and available for this support.
- PDS/E data sets are under member-level controls with the following notes and restrictions :
- When PDS/E member updates are processed by the Directory Entry Services (DESERV), the updates are controlled by the CAS4DSRV intercept. When a request is rejected, it returns a fatal error RC36 with security Reason Code 913. This can be seen when a linkedit using the binder fails with the following message:IEW2709S D50F WRITE OF DIRECTORY ENTRIES FAILED FOR DDNAME SYSLMOD. DIRECTORY SERVICES ISSUED RETURN CODE 36 AND REASON CODE 27130913
- When restoring a backup copy of a PDS/E Load library, a same message failure will be received in case the security intercept fails the request.
- Currently, the only case when IEBCOPY to a PDS/E can be member-level protected is when an IEBCOPY job is loading a program to a PDS/E from an IEBCOPY unloaded (backup) data set. Other IEBCOPY functions implying a member-level protected PDS/E like copy between PDS/E libraries cannot be protected using the member level protection feature. General restriction needs to be setup at data set level using standard data set rules when IEBCOPY is intended to be used with PDS/E.
- Program fetch for execution of load modules is not under member-level controls. This type of access is protected through the existing PROGRAM resource class.
- Execution of members of CLIST libraries that are enabled for VLF caching is not under member-level controls.
- Users still need proper data set access through access rules in addition to member-level access. That is, to read a PDS member, the user requires read access to the data set through data set access rules, and read access to the member through PDS resource rules.
- Users with ALLOC authority to a data set are able to bypass member-level protection controls because of their ability to rename the data set to a name outside of member-level protection.
- When an alias member name is accessed, the true member name is used in the member-level validation.
- TheCA ACF2resource exits are not taken for member-level validations. The z/OS SAF router exit, ICHRTX00, can be used to modify the validation. The resource validation call is a RACROUTE FASTAUTH and can be recognized by the valueCAPDSin the SUBSYS and REQSTOR fields.
- If you are planning on using PDS member-level security, you must have CA Common Services installed into LNKLST or LPALST, or add to theCA ACF2procedure a STEPLIB statement that points to the library where CA Common Services is installed.
- PDS member-level security validation process responds in one of two ways:
- User is denied access and the task abends with S913.CA ACF2can only report what is returned back from the IBM RACROUTE process. Therefore, S913 abend serves as a tool to describe why the user is denied and from what PDS library.
- The S913 abends does not mean the TSO ISPF user will be forced to logoff from their current ISPF session. Events are executed depending on what level of access(s) is given to the TSO ISPF user.
- Task abends with S913.
- User receives a warning message informing them that they are denied.
- User is returned back to the PDS member to allow them to cancel out.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ISPF processor ended abnormally * * * * * * * * System abend code 913 * * * * Reason code CA * * * * * * * * * * * * * * * * Note: The ABEND and REASON codes displayed above are * * * * HEXADECIMAL values for "SYSTEM" abends and DECIMAL * * * * values for "USER" abends. * * * * * * * * Enter HELP command for list of common ABEND codes. * * * * Press ENTER key for additional DIAGNOSTIC information. * * * * Enter END command to display primary option menu. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
The PDS member-level protection component is started automatically by
CA ACF2when GSO PDS records are present. The initialization program name is CAS4INIT. A message at
CA ACF2startup or refresh indicating that module CAS4INIT cannot be found means that the member-level protection component has not been properly installed.
Utility programs CAS4STAT and CAS4TRCE are available for problem resolution. Technical Support might ask that you run these programs.
CAS4STAT displays overall system status, location of key modules and other statistics. Run a job with the following EXEC statement:
//PDS EXEC PGM=CAS4STAT,REGION=6M
CAS4TRCE enables tracing from the member-level protection component. Trace messages are issued to the system console using WTO. Run a job with the following EXEC statement:
//PDS EXEC PGM=CAS4TRCE,REGION=4M,PARM='opt'
- ONEnables general tracing.
- SECEnables tracing of security processing.
- CCWEnables general tracing and also traces CCW I/O activity against a protected data set. This setting can potentially generate a lot of output and, depending on how many data sets are protected, impact system performance.
- MEMEnables general tracing and also generates tracing showing PDS member information including disk address translation. This setting can generate an abundance of output.
- DSREnables tracing of the events from the CAS4DSRV intercept.
- ALLEnables all tracing.
- OFFDisables all tracing.
Utility program CAS4TERM can be run to disable the PDS member-level protection component. To accomplish this, run a job with the following EXEC statement:
//PDS EXEC PGM=CAS4TERM,REGION=4M
To reenable the component, run a job with the following EXEC statement:
//PDS EXEC PGM=CAS4INIT,REGION=4M
The authority to run the CAS4TERM, CAS4STAT and CAS4TRCE utility programs is controlled by the FACILITY security class. The default type code for FACILITY rules is FAC. The resource rule $KEY values that let a user execute these utility programs are as follows:
For example, a rule to allow a system programmer to run the CAS4STAT and CAS4TRCE programs, but not the CAS4TERM program, follows:
SET R(FAC) $KEY(CAPDSSEC) T(FAC) TERM UID(*) PREVENT STATUS UID(sysprog) ALLOW TRACE UID(sysprog) ALLOW